Setting the Stage
This was my first project after joining Terminus, and it was a big one!  Our product at the time was roughly broken into two parts: the wizard that allows customers to create account based ads and reporting functionality for those ads.  
Engineering and Product drove the initial need for the rewrite.  As a company, we had chosen to change front-end frameworks from Rails to Angular, and this was the first major project to be "done right" in Angular.  Interestingly, we had two wizards at this point. One was the legacy wizard written in Rails, and the other was the first attempt at a wizard in Angular, written to accommodate our new integration with LinkedIn.

The whiteboards got a workout for this project!

The Research
Fortunately, the LinkedIn wizard was in production and actively in use by early access customers, which meant I was able to interview users of both wizards to understand the strengths and weaknesses of each design.  While I conducted the interviews, I compiled best practices for wizard (and form) design, as well as a heuristic analysis of both of our current wizards.  One of the key challenges designing a wizard is balancing the amount of information per page and the number of pages. Too much information per page and users can get overwhelmed - the whole point of a wizard is to break a complex process into smaller steps.  On the other hand, users hate being confronted by a wizard with 10+ steps, especially if some of the steps relate to each other and they are constantly moving back and forth to reference other information. As I found out, our Rails wizard was an example of the first problem and our Angular wizard was an example of the second problem.  My interviews with customers confirmed these problems, as well as the desire for more contextual help on each step. New users in particular would sometimes fill out a step without fully understanding the implications of their actions, causing problems down the line.

Early high fidelity mock

The Design
While I was completing the research, I started to sketch ideas for how to improve the experience while still maintaining the look and feel of the previous wizards, so our current customers wouldn't need to relearn how to use our product.  I moved from the whiteboard, to Balsamiq, to Sketch, making sure to get feedback at each stage from customers, Product, and Engineering. As Engineering dug in, we collaboratively identified technical and UX challenges that needed to be addressed.  I also worked closely with UX Engineering to identify components (such as the fancy visual radio buttons above) that we would need so they were ready in our design system by the time Engineering was ready to implement them. Things weren't all roses and butterflies, but by working closely together we were able to identify and resolve issues quickly as they arose.  
Beyond
As a core aspect of our product, improvements to the wizard are never truly complete.  6 months later, we're working to expand our definition of channels as we create more integrations, while also fixing issues we hear from customers about usability.  Wizards and forms are extremely difficult to get right in one shot, and continuous improvement and discovery is the best way to build the best product for your customers.
Back to Top