It’s often easy to trace the line from a digital invention to its analog ancestor—usually you don’t have to look farther than the name. In the past, we organized our desktops with folders and discarded documents in the trash, but in the digital age we organize our Desktops with Folders and discard documents in the Trash.
In UX design, we see this in many of the online processes we design for, like form-filling (a simple digitization of the paper form) and wizards (those short, laminated manuals that used to come with anything you had to assemble). But where we don’t see it is the builder.
Nike’s “NikeID” product builder
Builders are similar to wizards—a process divided into more digestible, designable steps— but instead of filling out a form or completing a task, builders are for creating and customizing products. The builder’s closest analogue would be walking down the assembly line at a factory, directing the manufacturing process yourself (which, of course, didn’t happen very often).
In our age of personalization, builders are more common than ever. As consumers, we demand products perfectly tailored to our individual needs and preferences, and we want complete control over their creation.
While builders offer much more functionality than a typical wizard, the impact of both web modules on a user experience is dependent on how they are organized.
This begins by examining the process or product you’re building, and determining an appropriate number of steps a user must take to accomplish it. If you’re only offering a few customization options—size and color, for instance—don’t use a builder. At the opposite end of the spectrum, nobody wants to use a 20-step builder.
The difficulty comes in a thorough analysis of the actual building process, and intuitively dividing it into between three and six steps (depending on the complexity). If you’re unsure about this fundamental step, consider conducting some preliminary user testing.
Partitioning a lengthy process with complex user interactions into just three to six steps isn’t easy, and it’s likely those steps will still contain a sizable amount of information and customization options. To avoid confusing or overwhelming the user, it’s important to employ signifiers to guide them through the builder.
For starters, that could begin by numbering your steps and suggesting an order to complete them in. Unlike wizards, which enforce a strict order of completion, builders offer a little more flexibility—to return to our car example, it doesn’t matter if you customize the interior or the paint job first. But despite this, having a suggested order gives the user a bit more structure, and users like structure.
Porsche takes an extremely complex process, custom cars, and condenses it to 5 steps, each of them clearly designated
It’s likely your builder will be demarcated into screens or modules, but no matter how it is presented, each step should have a clear label and brief explanation of the screen’s purpose (if the label doesn’t convey it already).
It should be completely obvious to users what stage they are in the builder, what stages they have successfully completed, and how many are left before they’re finished. After the final step, the builder should summarize their choices and show the finished product.
Like wizards, users should be able to easily navigate through the different sections of the builder. But again, builders must take these navigation functions a step farther.
Builders should include standard navigation features: a ‘next’ button to advance through the steps, and a ‘back’ to return. It’s likely your builder we need an ‘undo’ function, especially if it’s a significantly complex one.
A ‘save’ function is also highly advisable when crafting builders—it’s likely users will want to exit the builder midway, and resume their process at a later time. Finally, it’s good practice to include a summary of their selections at the builder’s conclusion, allowing the user to review their choices and return to the appropriate step to make any last-minute adjustments.
Most builders can be divided into two halves: a visual of the product, and a selection of the customizable options users can make to the product. As the user peruses the different settings, it’s crucial for the product to update in real-time to reflect those choices.
This builder updates the product to reflect a user’s choices, but there’s no price indicator in sight
And don’t forget changing the listed price of the product to reflect a user’s selections as well. Customers don’t want to spend time tailoring a product to their desired specs, only to experience price tag shock at checkout.
Lastly, your builder should have appropriate default options for each step. The best defaults can predict the user’s preferences and streamline the building process. One of the best ways to do this is to base defaults off the user’s entry point into the builder. For example, if a user has entered the builder from a product page filtered by color and size, the builder should default to those filtered selections.
Many of the best practices for builders can be co-opted from their less-intensive counterparts, wizards. But builders require more deft designing and additional functionality, making their construction a bit more complicated than the standard form filling process.
If you’re interested in implementing a builder for your eCommerce website, or want to learn more about Codal’s design services, drop us a line or even check out our other work. Codal’s UX team is a passionate, experienced group, and we love to talk our trade.