Saris MHS Configurator
Creating a Product Tool with 400+ Combinations
(Hiatus in between)
Exploring a Product With Endless Possibilities
Buying a custom bike rack for your car is confusing—to say the least. How many racks do you need, are they compatible with your bikes, what else do you want to carry...and will it all work with your vehicle type anyway? And after studying this product line for months, how do you convey this to a customer who has only 15 minutes to fiddle with the tool and buy a rack?
After all, Saris’ Modular Hitch System (MHS) has over 20 product combinations and 400 user actions possible in the tool.
With such a wide array of options to choose from and shoppers being busier than ever, it would really help if there was a tool to experiment with and build the most optimal bike configuration tailored to the user’s needs. That's what we were tasked with creating for Saris, a B2C bike rack and lifestyle brand for adventurous people who enjoy the outdoors.
Understanding the MHS Challenge of 400+ Scenarios
The MHS product line is complex as package can be mixed with different bases, racks, and accessories; the possible number of combinations currently exceeds 20+!
Certain products are required while others are optional, and every action impacts their configuration (e.g. a smaller base limits how many racks they can carry)
There are also many different variables such as product weight, size, shape, and the number of slots on a base which makes certain products incompatible. Imagine you were a customer, you would be confused!The Stakeholder expressed to us that this was causing confusion for customers.
Researching Configurator Best Practices
We studied Yakima Exo, an industry leader in custom bike racks. They are our main competitor and offer a similar bike rack tool with different customization options. We noted their approach of taking different steps and their vehicle selection step. However, their product is much simpler than ours with less combinations and restrictions and crucially: only one base.
Since we have so many bases, we needed to aim be much more specific in our steps, error messages, and logic.
We also studied IKEA, Tesla, Porsche, Toyota, Mercedes, Nike and Stanley for their product configurator tools. Some main notes we picked up on were saving configuration, error messages, toast messages, and how they broke down their tool into simple, easily digestible steps.
We also looked at device statistics for saris.com and found that roughly 61% of users were on mobile compared to 36% on desktop. This helped us in prioritizing mobile-friendly and responsive design as a priority to increase sales. The tool may be harder to utilize on mobile due to the various actions and smaller screen size, so we had to accommodate for that.
Experimenting With Initial Logic & Steps
Initially, different layouts and orders of steps were tried with the configurator. These were shown to the Stakeholder and we discussed what’s best for the user given their needs and the business needs. They noted that that we needed something simple and that the Base needs to be the first main step.
It seemed initially that the products would include things like skis, coolers, and luggage. The Stakeholder wasn’t sure when these products would be coming in. Thus initially, we made the configurator with a multi-faceted approach in mind.
However, it became then clear to us later that the focus is mainly on bikes, and that other types of cargo are not of primary importance (and wouldn’t even be coming), thus they should not be on the same hierarchy.
Meeting with Stakeholders and Working Towards Our Goals
We debated on having the main controls of the tool on the left or right hand side. The right side was chosen because it feels more intuitive for a sense of progression.
We also settled on a Step-based approach, dividing the products like Bases, Racks, and Accessories into unique steps to guide the user through their journey. A step would only be accessible after competing the prior step.
Certain things are accessories with the Bases, so they were initially include in the Step 1 Base. Later, we made them popups and handled the logic that way as it was clearer to the user.
Roadblock! Unexpected Project Cancellation
The project was put on hold when the Stakeholder was leaving for business needs. This caused an unexpected roadbump for our design team, as we would pick up the project months later, with new requirements and with a new Stakeholder.
Thus, we had to restart our strategy and remain flexible and open to changing our designs.
Picking up the Problem Again
With a new Stakeholder and months passed, new requirements were on the table.
For example, we moved away from including the Swing Away acessory in Step 1.
We also went all out on error message logic with different scenarios, and toast message logic to make it very clear to the user what was happening when an action they took affected something else on their configuration.
Mobile was a challenge as everything needed to fit on a much smaller space whilst maintaining functionality of the tool.
Finishing Touches & Optimizing Conversational Design
We added a new initial screen where the user selects their vehicle in order to give a clearer sense of onboarding.
The My MHS menu was also bolstered with more substantial features for Dragging & Dropping products into different slots of the Configuration.
We also brought back the Undo, Redo, and Reset buttons to help users experiment more freely.
Along with the prototype, we handed off a spreadsheet of every possible combination user action and what would happen in each scenario to make it easier for the developers to understand the logic.
There ended us being 459 different product combinations with corresponding UX logic and many toast messages to account for in building the tool. I created this spreadsheet and wrote the messages to bolster the ease of use of the tool so the user.
Prototype & Developer Handoff
We handed off a Figma file with designs for desktop and mobile, along with an error sheet and a brief slide deck describing the tool to the developers that helped us communicate our design to them over calls.
Outcomes & Metrics
The product is currently still under development, so once this goes live, we plan on tracking how many change in sales of the MHS product line from before this tool and existed, the device size users are accessing the tool from, and areas of confusion with the tool. From these stats, we can improve the tool further.
Learnings & Takeways
Developer handoff was one area of learning from this project. It came to our attention that because of the tool’s various scenarios and error messages, the developers should have been involved earlier, given that at the start we did not realize there would be 400+ action scenarios. Working closely with the development team from the beginning would allow for a smoother design to code handoff.
Earning stakeholeder buy-in earlier is another takeaway as though we were in contact with one main stakeholder, the rest of the clientele we had to convince of our design at a very late stage into the project. However, the clients have edits at a later stage things become harder to change. Getting approval earlier on would ease these hiccups.
