Photo by Artem Maltsev on Unsplash

Sometimes, you might design for important but infrequent tasks, such as installing new software.

In those cases, you might want to rely on a design pattern that you and I might have grown up with: the wizard.

https://uxplanet.org/wizard-design-pattern-8c86e14f2a38

Wizards are decades-old design patterns that have fallen out of favor in place of dynamic forms. Still, that doesn’t mean there aren’t modern use cases where they’re often the right design pattern.

However, we’ve learned a lot since the pattern was implemented in the early 1990s: we’ve learned how to design well-implemented wizards by asking ourselves a few questions.

But before we get into that, we need to first understand how wizards differ from other similar design patterns.

Wizards, Onboarding, and Dynamic Forms (Oh my!)

Two common design patterns are often used today instead of wizards:

Both design patterns are often used in similar situations where you might use a wizard, but there are two critical differences between them and wizards: user input and discrete steps.

Onboarding is a method of walking your users through different features, aspects, or steps of a website that usually occurs the first time you launch an app or website.

https://www.nngroup.com/articles/mobile-app-onboarding/

However, this is often a 'feature preview': the user can't input anything other than to either move forward or skip the tutorial.

This is where another pattern, Dynamic forms, comes into play. These forms can show feedback like error messages in real-time, such as if a password is too short, without the user clicking "Next" to generate an error.

An older version of Live.com

These two patterns often cover most use cases that Wizards might typically be used. So what’s a Wizard intended for?

Wizards are about providing a step-by-step process that allows users to input information in a specific order, with subsequent steps possibly depending on the information entered in previous ones.

https://uxplanet.org/wizard-design-pattern-8c86e14f2a38

They often split complicated and complex tasks into multiple pages with smaller amounts of information per page. This also may be why wizards have fallen out of favor: user tasks nowadays are shorter and more straightforward, so there's been less demand to require users to walk through multiple wizard pages.

However, there are still two strong use cases for when to use wizards: walking novice users through a complicated process or helping them accomplish important (but infrequent) tasks.

For example, imagine that a user wants to set up a couple of newly hired people with a super-administrator role, which grants them special privileges and essential information. The user might be a novice to this process or an expert who doesn’t do this regularly.

As a result, they might want help in completing these tasks. After all, you don't want to grant this access to a random stranger if you screw up the process.

As a result, this is a strong use case for using a wizard. However, before designing a wizard, you must ask yourself four basic questions.

Four questions to help you design a wizard

Is the task complicated/infrequent enough to require a wizard?

One of the downsides of wizards is that they limit users' control and creativity, which can be problematic if you're working with expert users or if the task is something they'll frequently do. They're likely to get frustrated by the lack of control wizards offer them, not to mention the tedium they face when clicking through multiple pages each time.

So one of the first questions you might want to ask yourself is whether the task is worth the potential downsides. It might be that your enormous task might be easily simplified into several smaller and streamlined tasks.

For example, the “Signup” process might have had enough fields to warrant using a wizard at one point. Nowadays, with Single-Sign-on and other technologies, creating a new account for a website might be as simple as a few clicks.

If it still seems like your task is complex enough to require a wizard's “breaking down” process, the next step is to think about making discrete steps with as minimal typing as possible.

How can you break the process into steps with minimal typing?

If you had to break down a specific process into several steps, how would you do so? Unfortunately, this question can sometimes be tricky to answer, depending on the information users need to input.

Sometimes specific steps will divide nicely, such as inputting all of your username/password information before getting to the next steps. Other times, the necessary input fields might blend.

So one tip to approach this is to look for opportunities to reduce user typing. For example, if the user types out credit card information on one step, perhaps separate that step so that future steps can reference that without issues.

How previously entered credit card information can save users a ton of time.

One of the strengths of wizards is that they pre-fill future input fields (or hide unnecessary input fields) based on the user's previous responses. With that in mind, think about ways to design to minimize user typing.

Do you know where user and business workflows may differ?

One of the downsides of wizards is that there must be standardized steps that a user follows. As a result, if the business prescribes a specific workflow that doesn't make sense to users, it will cause a lot of frustration (and even harm) to get through this process.

So one thing that is necessary to develop a wizard is understanding how users accomplish tasks. You need to be able to interview users and learn their workflow towards completing specific tasks to understand if there are any differences between what they (and the business) do.

This leads to the last question.

How do you support exiting midway (and resuming)?

Like it or not, there may be interruptions to the user's workflow: for example, perhaps users are asked to complete other work during this setup process. As a result, users need to be able to save (and exit) midway through the wizard and pick up at a later date.

This can be especially important as some wizards might take a while to set up: for example, users may be waiting around for a server to boot up before clicking on the next step of a wizard.

It should also be obvious how to resume the wizard process: many wizards often allow the option to "Save and Exit" during a process, only to hide how to resume an existing wizard process (or force the user to click through already completed sections).

Wizards are best used for simplifying tasks and infrequent processes

While wizards have fallen out of favor, that doesn't mean there aren't use cases for them.

It may be tiring to use them daily, but when you're doing something you've never done (or haven't done in years), they can be a helpful way to guide users through a complicated process.

But keep these four questions in mind as you're designing a wizard to ensure that you're not making your users' lives harder. Doing so can ensure that your users aren't frustrated by the end of the process.

Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.