MenuClose
BUILDING A PRODUCT CONFIGURATOR
BLUEPORT
PROJECT CHALLENGE
Research and design a product configurator for mobile to be used in a B2B platform for furniture retailers..
TEAM
MY ROLE
UX Researcher
UX Designer
TIMELINE
3 week sprint
January, 2022-February, 2022
TOOLS
- Figma
- FigJam
- Trello
- Google Workspace
PROTOTYPE
PROJECT BACKGROUND
We were approached by Blueport to help them design a product configurator. Blueport’s Cloud platform provides e-commerce services for big-ticket item retailers. Their current clients include American Signature Furniture & Steinhafels, a mattress retailer. The Blueport team was primarily looking for us to conduct usability testing of existing configurators and to translate that research into an original design for their platform. Sounds straightforward, right? Little did I know just how deep designing a product configurator can take you….
WEEK 1
ConFIGURING
IT OUT
I’ll be honest– when we were first approached by Blueport to work on a product configurator, I had only a fuzzy idea of what a product configurator actually was.
We quickly realized that there are ample options for integrating third-party software into existing platforms. When asked, Blueport explained that these products would not allow for the high level of flexibility needed for their B2B platform.
My team and I set out to research product configurators in general. We wanted to understand four main elements:
FEATURES
What are key features common to all product configurators?
FUNCTION
How do existing configurators look and function?
DEVELOPMENT
How do configurators work from a development perspective?
DESIGN
How do configurators work from a design perspective?
PRODUCT CONFIGURATORS
FEATURES & FUNCTION
We explored product configurators from a variety of industries– automotive, interior design, and even expensive Swedish strollers. We quickly understood that these configurators had key elements in common:
- Modular build to allow for modification of discrete elements within the product.
- 3D-renderings of the product which live update based on modifications.
- Updated pricing depending on modifications.
PRODUCT CONFIGURATORS
DEVELOPMENT
Although our team was not responsible for developing the configurator, we felt it necessary to understand at a basic level how they function on the back-end. in order to ensure that our design would be logical and achievable.
We researched HTML form elements, scanned briefly through open-source code for product configurators, and learned how to create basic product configurators using Microsoft Excel. This research helped us understand how development constraints would inform our design.
PRODUCT CONFIGURATORS
DESIGN
Initially, we primarily looked at configurators on desktop. But as we became more familiar with what configurators are and how they function, we began to explore the next step of our challenge: designing for mobile.
We quickly identified that configurators fall into the same issue common to much of mobile design: the lack of horizontal space compared to desktop.
Android’s Material Design provided significant inspiration for how to maximize the amount of visual real estate available on mobile.
WAYFAIR Product Description Page- no configurator
BURROW Product Description Page- has configurator
FURTHER RESEARCH
COMPETITIVE ANALYSIS
While we tried to develop a deeper understanding of product configurators in general, we also began to analyze the sites of various competitors previously identified by Blueport: Wayfair, Burrow, Bob’s Discount Furniture, Purple, and Tuft & Needle.
To our surprise, of all the direct competitors, only Burrow currently uses a product configurator on their site. By comparing Burrow’s configurator to the other sites, we further honed in on the difference between configuration and customization. As show in the screenshots on the left, Wayfair’s site allows for a level of customization but not configuration. The user only has the option to select fabric color, and when they do so, the page loads a completely different image showing the sofa in that color. In comparison, Burrow’s sofa has a modular build which allows for.a variety of configuration options and displays changes through a live-updating 3D rendering.
WEEK 2
GETTING TO KNOW THE USER
We’d asked about users during our initial meetings with Blueport, but didn’t yet have a strong enough sense of their behaviors and motivations to drive our design. As Blueport explained, the furniture-buying market is demographically enormous. Creating highly-defined personas isn’t necessarily useful for their business. All we knew was that they tend to focus on consumers aged 25-65. Within such a broad group, how could we ensure that our feature would meet user needs?
Although it was not initially a part of the project brief, we realized that conducting user research would be crucial to our process. We decided to devote a day–all that we could spare within our timeline– to user interviews. We would then use our interview synthesis to develop proto-personas– broad stroke personas that help define user behaviors, needs, and pain points while excluding any type of demographic information. Our interview script sought to understand consumer attitudes and motivations towards online shopping and clarify when users develop caution towards big ticket items.
USER INTERVIEWS
EXAMPLE QUESTIONS
What are your primary considerations when you shop online as opposed to in-store?
What types of things would you hesitate to buy online? Why?
Tell me about your last experience buying furniture.
Did you buy online or in person? What influenced this decision?
Did you customize the piece of furniture at all? If so, what was that like?
If you have shopped online for furniture before, what were your top considerations?
How did you feel about not being able to touch the furniture prior to buying?
USER INTERVIEWS
AffiNity MAPPING
We conducted 6 total interviews within a demographic representative of Blueport’s stated age range. Affinity mapping as a group allowed us to uncover some common themes, written as “I statements,” within our interviews.
“I develop trust through detailed research.”
“I need to have a tactile experience in order to feel comfortable.”
“I’ll go with whatever option is most convenient.”
“I feel confident shopping online when buying expected items.”
“I value interpersonal connections during the shopping experience.”
“I prefer to shop at brands that are ethical/unique.”
“I need a high quality, detailed site to feel trust.”
SYNTHESIS
PROTO-PERSOnAS
Proto-personas revealed themselves naturally through the process of affinity mapping. These personas helped us understand what different customer types would need and value during their online furniture-shopping experience. We were one step closer to being able to design a configurator that would actually respond to real user behaviors.
INTERIOR DEFINE PDP
INTERIOR DEFINE Color/Fabric selection
INTERIOR DEFINE Other options
APT2B Product Details Page
APT2B Color selection
APT2B Drag & Drop Build feature
USER RESEARCH
USABILITY TESTING
Conducting usability tests of existing configurators was possibly the most illuminating part of our overall process. Blueport had emphasized to our team that this was what they most needed from the project. With their support, we were able to recruit 6 testers from userinterviews.com.
As a team, we developed a testing protocol which we then ran by the client before proceeding. Since sectionals tend to provide the most opportunities for configuration, we decided to test the product configurators for sectionals from Interior Define and Apartment2B. We asked users to imagine that they were currently seeking a sectional for their home and. to show us how they would go about customizing that item.
On Day 1 of testing, we presented the testers with Interior Define then Apartment2B. Testers uniformly preferred the experience offered by Interior Define, highlighting its ease of use, detailed descriptions, and accurate renderings. In contrast, they expressed frustration with Apartment2B’s Build feature, often giving up and moving on to other configurator elements. The also expressed frustration with the limitation of Apartment2B’s top-down view as opposed to Interior Define’s 360° rendering. Would the reaction be different, we wondered, if users were presented with Apartment2B’s configurator first and Interior Define’s second?
On Day 2 of testing, we presented the testers with Apartment2B’s configurator first. Somewhat to my surprise, the testers continued to react negatively to the experience. Our first tester of the day nearly quit the test entirely, not two minutes in, so frustrated was she with Apartment2B’s Build feature. We gently persuaded her to continue, but were struck by her exasperation. If this user had encountered the configurator while actually shopping for a sectional, she surely would have closed the page in annoyance. The next user was one of two testers to understand intuitively how to use Apartment2B’s configurator, and expressed contentment with the experience, but even this paled in comparison with her delighted reaction to Interior Define.
The tests allowed us to zero in on the elements that worked most and least for users for these two configurators. Through further analysis of the tests, it became increasingly clear that our design should would benefit from an approach closer to that of Interior Define.
USABILITY TESTING Metrics Table
USABILITY TESTING
METRICS
After testing was complete, we reviewed our video and notes to evaluate each user’s experience according to the KPI’s we’d identified prior to testing.
As can be seen in the chart, Interior Define vastly outperformed Apartment2B, with an overall score of 41/45 compared to Apt2B’s 27/45.
INTERIOR DEFINE User Flow
APARTMENT2B User Flow
USABILITY TESTING
USER FLOWS
Additionally, we developed user flows to represent the 6 testers’ experiences of the configurators. Notably, we included a FAIL path for Apartment2B, based on the users who indicated that were they not participating in a paid usability test, they would have given up on the experience.
The user flow for Interior Define helped us visually represent the one consistent drawback of their configurator– the need for the user to constantly scroll back to the top of the screen to check whether their modifications had been represented in the 3D rendering of the sectional.
We began to ask ourselves how we might design a configurator that emulated the delight, ease, and transparency of Interior Define while avoiding what we deemed “the scrolling problem.”
INTERIOR DEFINE Journey Map
APT2B Journey Map
USABILITY TESTING
JOURNEY MAPS
As testers had expressed such strong and clear emotional reactions to the configurator, we also decided to create two journey maps to represent the affective experience.
This led me to wonder… why did our testers have such strong emotions about product configurators? Clearly the experience was about more than just having the functional ability to customize a piece of furniture. I pondered some key insights from our users:
Then it came to me. Product configurators are not just a means of being able to customize a product. They are opportunities for the vendor to build trust, confidence, and delight within the user. This is particularly crucial when it comes to buying big-ticket items online, an experience that asks the user to place a great amount of trust in the company.
WEEK 3
DIVING INTO DESIGN
We began our pen & paper sketching with these thoughts in mind:
- How can we design a product configurator that emulates the best elements of Interior Define while avoiding the scrolling problem?
- How might we use the configurator as an opportunity for building trust, confidence, and delight within the user?
DESIGN ITERATION
SKETCHING
We first sketched individually, then brought our sketches together in a FigJam board to review. We identified the commonalities between our various ideas and highlighted particular features from different sketches that we felt would be effective.
These sketches show how we each grappled with maximizing horizontal space and avoiding the scrolling problem. We returned to the Android’s Material Design for inspiration, experimenting with container transforms and backdrops. Ultimately, we decided to base our configurator design on these four sketches.
LOW-FI WIREFRAMES, Condensed Wireflow
DESIGN ITERATION
LOW-FI WIREFRAMES
In order to start building the wireframes in Figma, we first traced over the PDP for American Signature, one of Blueport’s clients and a likely future user of Blueport’s product configurator. We wanted to ensure that our design would sit naturally within the existing design. Tracing allowed us to move elements of the existing page to make room for the configurator while retaining the realism of the existing product page.
Unlike Interior Define, which asks the user to scroll down the page in order to use their configurator, we decided that the Blueport configurator feature should be a child element of the PDP parent page. Once the user is inside the configurator, they change screens through “sibling transitions,” with screens sliding left-to-right as they move through the configurator.
DESIGN UPDATES, Usability Testing Round 1
DESIGN UPDATES, Usability Testing Round 2
DESIGN VALIDATION & REFINEMENT
USABILITY TESTING
The changes my team had made to avoid the “scrolling problem” substantially changed the user flow from the pattern established by Interior Define. To check whether our design solution was intuitive and logical for the user, we conducted two rounds of usability testing on our clickable prototype. Our prototype usability tests used a nearly identical protocol to our earlier tests of Interior Define and Apartment2B to ensure that our configurator met a consistent standard previously established.
TESTING, ROUND 1
Our first round of tests clearly and quickly identified critical issues with our initial design. Our three testers were consistently confused by the same elements.
The initial design included the configuration menu embedded within the PDP, underneath the product images. Unfortunately, this area of the page was off screen, causing our users to miss it entirely. Without seeing the configuration menu, they did not have a clear idea of how many steps were involved in the configuration process or what the order of the process would be. We modified the design by moving the configuration menu into the child element opened from the PDP. This way, the user would notice the menu as soon as they clicked the “Customize” button. Users were also confused by the page numbering within the configurator feature. We attempted to clarify this by writing the steps as “1 of 8” rather than “1/7” and removing the numbering in the pages’ bottom navigation.
TESTING, ROUND 2
To test the changes from round 1, as well as any other potential issues, we conducted one final round of testing on our prototype. Three different testers walked through the prototype using the same protocol as the previous test.
We were pleased to see that users no longer had issues with the numbering within the configurator, but noticed that there were still problems with the configurator menu page. In spite of the buttons being numbered, with a grey path showing the journey from start to finish, some users were still unsure of how to begin using the configurator. One user even began by clicking “Preview Sectional,” a feature which would only be possible to view if one had already customized their sectional. We addressed these issues by adding a line of text prompting users to start by choosing fabric as well as removing the option to begin customization by clicking the bottom navigation. Additionally, we greyed out the “Preview Sectional” button to signal that this feature would be unavailable at this point in the flow. Finally, we rounded the corners of the buttons in order to make them appear more clickable.
Users were also confused when asked to edit their configured sectionals after going through the customization process and arriving at the Order Summary. Based on our testers’ feedback, we made the “Edit” button larger and placed it next to the “Add to Cart” button.
With that, we were ready to present our product configurator to Blueport.
THE FINAL PROTOTYPE
LOW-FI PROTOTYPE
View video of clickable prototype.
CONCLUSION
DID WE CONFIGURE IT OUT?
We began this project mired in doubt and confusion and ended it three weeks later knowing more about product configurators than I’d ever realized was possible. Our client was extremely pleased with the work, remarking on our team’s thorough exploration and innovative design solutions. They also noted that the low-fi wireframes were at the exact right level of fidelity for the project brief, considering that the Blueport configurator will eventually take on a variety of skins depending on their client’s website.
While our team was satisfied with the conclusion of this project, there are, as always, several next steps that we would take were we to continue working on the configurator:
- Experiment with previous sketch ideas. While we worked out usability issues during our testing, I would be curious to know whether some of the ideas left on the drawing board would be even more effective.
- Further iteration & testing of user flow in existing prototype.
- Further iteration & testing of UI elements (button styles, dropdowns etc.) in existing prototype.
- Testing prototype with multiple types of furniture (dining sets, mattresses etc.)
UPDATE
RECONSIDERING & RECONFIGURING
A month after presenting the product configurator to Blueport, I decided to revisit the project on my own. I felt that in spite of our best efforts, the user flow established in the prototype still had some issues with ease and intuitiveness.
The problem lay not in how to move through the configurator itself— once users were within the child element, they had little issue scrolling through and using the different configuration screens. Rather, users remained confused by the “Customize Your Sectional” menu screen, still unsure whether the buttons were clickable and how to actually begin the configuration process.
How could I:
- continue to avoid the “scrolling problem,”
- make users aware of the steps they would encounter before starting to customize,
- allow users to jump back and forth non-linearly between steps if they wanted to go back and modify and prior decision?
DESIGN ITERATION
BACK TO SKETCHES
I revisited our previous sketches to spark some ideas about how to resolve this issue. This sketch (left), seemed to suggest some possibilities for using a making all configuration options visible at the same time and allowing the user to jump back and forth between steps. Yet the buttons for each step seemed too small and crowded to work effectively on mobile — our original reason for not pursuing this idea.
What if, however, the configuration steps were presented as a modal menu? This would allow me to use the entire length of the screen for the buttons without them getting in the user’s way. I began to experiment with this idea in Figma.
DESIGN ITERATION
WIREFRAmes, Revisited
I redesigned the configurator’s header to include a hamburger menu to activate the sidebar menu, which included all the configuration steps. I also decided that as soon as the user clicks “Customize” on the PDP, the configurator should open with the sidebar menu active. This would allow them to visual all the steps and know how to move back and forth non-linearly, if desired, through the configurator without appearing as a confusing separate screen.
DESIGN VALIDATION
USER TESTING THE UPDATES
I recruited three new users to test the updated app prototype. While the modal menu certainly lessened the confusion that users had experienced with the “Customize Your Sectional” page, one critical issue remained: no user was certain about the functionality of the header’s “X” button. We had initially included that button as a way for users to exit the configuration back to the PDP without having to move through the entire configuration process, but none of the three testers used it as such. One user clicked the “X” multiple times while using the configurator, thinking it would close the current screen and take him to the next screen, only to frustratingly be deposited back on the PDP each time. I tried testing again with a back arrow symbol rather than an “X,” but ran into the same issue.
This round of testing illuminated something critical: the header did not follow typical design patterns. Users are accustomed to clicking on the left of the screen to move forward and the right to move back…. and my header had it the other way around.
FINAL UPDATE
EASE & INTUITION
Based on this final round of testing, I made several changes to the wireframes and prototype:
- Header— I moved the hamburger menu to the left of of the header to better align with expected designer patterns. I also removed the back button from the header entirely. Testers had expected that the back button would take them back to the previous configuration page rather than back to the PDP. I instead added a “Leave Customizer” button to the modal menu. The additional text allows user to better understand the effect of that button and its placement within the sidebar better keeps the user in the funnel.
- Image highlights— While the sectional illustration is intentionally low-fi, since the configurator will ultimately be used for all kinds of products, I decided to add blue highlights to the areas being modified within each screen. The feature allows the user to better identify the impact of their actions while using the prototype.
CONCLUSION
(REALLY, I MEAN IT THIS TIME)
Although the initial configurator design presented to Blueport had received glowing feedback, I had been left with the nagging feeling that there was something more I could do to improve the user experience. One of the things I love most about design is that its iterative— the process welcomes improvement, revision, and experimentation based on feedback. By embracing iteration, I was better able to meet user needs while staying aligned with design goals and business objectives.
