Wizards: Definition and Design Recommendations

When it comes to inputting data, the two most common patterns used on the web and in applications are forms and wizards. The electronic form is a direct descendant of the paper form: a page with empty fields that the user needs to fill in. The wizard is a minapplication that takes the user through a sequence of forms.

Definition: A wizard is a step-by-step process that allows users to input information in a prescribed order and in which subsequent steps may depend on information entered in previous ones.

Wizards usually involve multiple pages and are often (but not obligatorily) displayed in modal windows. One wizard page typically corresponds to a single step in a multistep process.

As the user enters information, the system computes the appropriate path for that user and routes her accordingly. Wizards thus often have some branching logic behind the scenes, but the perceived user experience is that of a linear flow: one screen after another, and all the user has to do is to click “next.” (Or “back,” or “cancel,” but mainly the user keeps moving forward.)

A classic dilemma in user interface design is whether to allocate control to the user or to the computer. Usually, people feel better when they are in control, but having too much freedom might get the user into trouble and will often cause them to waste time. Wizards allow the computer to control the flow of the dialogue, but this limitation of users’ freedom can be liberating in cases where people don’t care about their choices or don’t know enough to make a decision.

Dynamic Form or Wizard?

With the prevalence of AJAX technologies, the distinction between form and wizard has become fuzzier. For example, the Fidelity page below asks users whether they are current Fidelity customers, and, depending on their answer, shows on the same page either login fields or name and email information. Is this a form or a wizard? According to our definition, it’s a wizard.

The Microsoft page below also changes the information displayed on the screen as the user enters information — but, in this example, the fields stay the same, while inline error messages or explanations appear as the user progresses. Technically, this page is a form and not a wizard — the steps of the process are not modified by the actions taken by the user, although the form does give dynamic feedback to users as they fill in the different form fields.

Wizards Show Less Information on the Page

Because wizards split a complex process into multiple steps, often wizard pages are simpler — they contain fewer fields and overall less information. Page simplicity has several important benefits:

• Users end up being less overwhelmed by the process. A long form is often daunting and users may overestimate the amount of work involved in filling it.
• Less cognitive effort is spent in completing the process. Much of the information in a form may end up being irrelevant, yet people will have to spend attentional resources to scan it and eventually filter it out. With a wizard, the fields displayed depend on users’ previous input and have better chances of actually being important and not just a distraction.
• Users make fewer mistakes. With an overly complex form, users may ignore certain parts and be more likely to cause form-submission errors. Or, they may miss something that is relevant for them.
• More screen real estate is available for each step. When a complex process is split into simpler steps and each step gets a separate page, there is simply more space for each of the controls in a step. Targets can be bigger and less crowded, information may fit on a single screen (so no scrolling will be necessary), and explanations may be displayed next to the fields.

Shortest Path for Each User

For some people the path through the process may be quick and simple, while for others it may be intricate and tedious. If the process is forked depending on users’ inputs and the forking is transparent to the users, then they don’t need to bother with the path that does not apply to them. Thus, in a well-designed wizard, people will only see the steps and the information relevant for their situation.

For example, users who don’t own a credit card need not see the credit-card fields in a checkout form and could focus instead only on the relevant-to-them PayPal fields.

Disadvantages of Wizards

As helpful as wizards are, they are not appropriate for all situations. Here are some common problems associated with wizards:

Compare, for example, the process of typing data into a spreadsheet with multiple columns with that of entering the data field by field in a wizard. The repeated switching between the mouse and the keyboard and the extra attention demanded by a changing display can quickly become tiresome compared with just tabbing through the different columns of the spreadsheet.

• Wizards can require a higher interaction cost (more clicks) than other input patterns. Especially if wizards need to be invoked repeatedly, the tedium of clicking through each of the steps can overwhelm the advantage of splitting the process into small sections.
• Wizards might not allow users to easily transfer or compare information from different steps. When users see one step at a time, it can be hard to move information across steps or refer to information entered or presented during a previous step. (And, sometimes seeing more steps at a time can give users some additional context to better understand the information requested in each step.)
• Wizards are not gracefully interruptible. If users quit the process midway, they might not only lose their work, but may need to click again through the preceding steps. Even when the wizard supports the saving of the state and resuming of the process at a later date, it can be difficult for users to remember what they were doing and recover their context and the mental model of the process.

  (That being said, forms are not gracefully interruptible either — most of the time, the information entered will be lost if the user stops midway, and even in the event when that information is saved, users will still need to recover context.)

• Wizards may block access to other parts of the app that are necessary for completing the process. When the wizard is presented in a modal window, it can obstruct information in the background that may be relevant for the current process. Most often, it also prevents users from interacting with other parts of the site.
• Wizards limit the users’ control and creativity. While it would be appropriate to supply a wizard for amateur photographers to improve the color balance of a photo, it would be too limiting for a professional graphic designer to use a wizard to improve an image.

Recommendations for Designing Usable Wizards

1. Use wizards for novice users or infrequent processes (e.g., configuration or setup).

   Wizards can help users with little knowledge about a domain by simplifying the processes and by guiding the users. However, as we saw before, wizards can quickly become annoying and overly controlling if they have to be used over and over again or if users have a lot of knowledge of the domain and their mental model of the process is different than the mental model implemented by the app designer.

   Basically, use wizards for situations where the users are likely to be unfamiliar with the process — either because they don’t have a lot of domain expertise or because they go through that process only rarely. If you expect that some of your users will perform it repeatedly, consider offering them another faster alternative for inputting their data.

2. Communicate a clear mental model of the process by displaying a list or a diagram of the steps involved and highlighting the current step.

   Because the process is presented one step at a time, there is danger that users will miss the context, get confused, or not realize how long the progression will be. It best to set the right expectations and explain to the use what the process looks like and how many steps are involved.

   Especially with complicated processes, a clear labeling of each of the steps as well as a clear indicator of the current step can help keep users oriented.

   

3. Enforce a clear sequential order of the steps. Do not allow users to pick step before completing the steps preceding it.

   Although logically it may make no difference if users start with the last step in the process, having a clear ordering minimizes decision making (and sometimes the memory load as well, if the completed steps are not clearly marked and users must remember which steps they’ve already visited) and thus simplifies the interaction.

   (If there are substantial benefits to users from being able to complete steps in an arbitrary sequence, then this is an indication that this functionality is not suited to be provided as a wizard.)

   

4. Include buttons for navigating to the next and previous steps and label the steps descriptively. The general guidelines for button names stand for wizard buttons as well: Generic labels such as Next and Previous have weak information scent and don’t tell users anything about these steps. It’s better to indicate in the label what the user will actually have to do next.

   In the Mini example above, the button for the next step is clearly marked with the name of that step. However, there is no explicit button for going back to the previous step. (Users can still do it by selecting the tabs at the top of the page.)

5. Allow users to exit the wizard midway and save state. Allow them to resume the process at a later time.

   Interruptions happen, and users should be able to save their work and later continue the process from where they left. They will still incur the cognitive cost of recovering context and remembering their goals, but at least they will not have to reenter the same information.

   In the examples above, neither Veeam nor Mint allow users to save their work. One can perhaps argue that the Mint wizard is so simple and short that saving state will only complicate the interface unnecessarily. However, in Veeam’s case, the process is fairly complex and central to the app, so being able to finalize the setup for a new job at a later time is important.

   Mini’s wizard includes a Review & Save button that allows users to stop their work at any time and save it in a file that can be retrieved at a later time. Unfortunately, the placement of that button at the top of the page is far from users’ current focus of attention and makes it easy to ignore.

6. Wizard steps should be self-sufficient and not require information available elsewhere in the app (or in a previous step). Make sure that users can easily access all the info that they need as they use the wizard. The Mint example above violates this guideline by requiring users to get their credit scores from elsewhere.

   

7. Help and explanations should appear in a window next to the wizard and should not cover the wizard. Any descriptions of the terms or the fields in the wizard should be viewable next to the wizard and should not cover the fields in the wizard. In this way, users will be able to apply the information in the explanation window to the wizard context.

   

8. Consider reusing the user’s selections from previous use as the defaults for the next use of the wizard. For many tasks, users will benefit if the system remembers their selections and input values from one use of a wizard to the next. The very first time a user employs a wizard, the designer should have chosen appropriate default values, and there are some applications where those standard values should be the default every time.

Conclusion

Wizards are a powerful design pattern that can be used to simplify complex processes performed infrequently or by novice users. By showing less information at a time, they allow users to focus better on the content pertinent to each step and decrease the chance of errors. When they include branching based on user input, wizards ensure that people will see only the steps applicable to their situation. Some of wizards’ disadvantages can be mitigated by thoughtful design ensuring that the process steps are clearly communicated to the user and they are independent and self-sufficient.

Learn more about wizards in our course Application Design for Web and Desktop.