Design system: Designing a Wizard

Context

I was tasked with designing a Wizard pattern to be included in Hitachi's Next Design System.
There were a lot of different aspects I needed to consider to create something that would be flexible enough to cover many use cases, requirements, and screen sizes.
To achieve that flexibility level, I had to think about all the micro-interactions that can take place in such a complex pattern and also consider the unhappy path for error prevention.

Problem

Users get overwhelmed with long forms full of inputs, especially when the task is somewhat critical (for example, setting up new software).

‍

Problem statement

• The user needs to focus on the task at hand.
• Some users will require assistance going through many fields, inputs, or questions.
• The user must feel safe about submitting critical information into the system.
  
  ‍

Research and problem definition

I started by researching the concept of progressive disclosure and found this fascinating article written by Tania Langin Peak XD called Responsive disclosure, forms & FrodoBaggins.

The basic idea is easy to grasp when laid out in such a simple way: "Do you think Frodo would have agreed to take the Ring to Mount Doom if he knew he’d get stung and almost eaten by Shelob, stabbed by the Witch-King of Angmar, captured by the Orcs of Cirith Ungol, and his finger bitten off by Gollum, not to mention a very long walk with no second breakfast? Hell no! Had he known all this, he probably would have turned right around and rushed back to the Shire to Bag End. And where would Middle-earth be? Thankfully, Frodo’s quest didn’t seem so hard when he started off and it was only as he progressed through his journey that each of these challenges took place." 

Segmenting the tasks will reduce user errors, ease stress and confusion, and build trust.

On that note, trust is a fundamental key. Most of us have had that awful experience completing a very long form, and only by the time we submit it, we get unclear error messages and, on the second try, notice that the system did not save our information. Or to click on the submit button, but our crappy internet connection makes us nervous that we will lose everything.

One of Maslow's pyramid of needs is safety, the fundamental need to feel secure and protected. In an online environment, we need to feel safe from losing information or worse, money! That is why so many e-commerce websites use “site seals”, such as trust badges, SSL seals, and similar symbols suggesting trustworthiness.
‍

So after this research, I concluded that:

‍
1. We need to segment the tasks clearly to the user; we want them to feel safe throughout the process.
2. We need to provide feedback about the status of the overall process.
3. We need to avoid information loss, so this pattern works best on fullscreen modals where the navigation is obscured. Or, in the case of a modal, disable the possibility of closing the modal by clicking outside of it. In all cases, we'll need confirmation dialogues if users cancel the wizard midway through completion.  
 
We can apply this pattern to different use cases, such as:

‍

‍

Solution space

In pursuing minimalism in the UI, my first design decision was only to display the step name for the active (current) step.

Even though the UI would be cleaner and less cluttered, the user would only know what the next steps are if they hover the dot, and that might prevent them from skipping a step (if there are no mandatory fields).

After receiving feedback from other designers in the organization that they felt like knowing all the steps was important, especially for critical activities, I decided to have all sep names visible on Desktop mode and only have the previous design on the mobile version.

This approach meant that I needed to tackle scenarios like a lot of steps, long step titles, and responsiveness in the desktop version.