Contents


Crafting a wizard

Fifteen dos and don'ts for designing wizards that make complex tasks easier for your users

Comments

What is a wizard?

A wizard is basically a series of screens or dialogue boxes that walk users through completion of a task. Generally, each wizard screen asks users to enter information, either by making selections, or filling in fields. After entering required data, users navigate through a wizard by clicking navigation options like "Back" and "Next." At the final step, users click "Finish" to indicate completion of the wizard.

When should a wizard be used?

According to the experts at User Interface Engineering (see Related topics), wizards should be used when:

  • Users want to accomplish a goal that has many steps
  • Users lack the necessary domain knowledge
  • Users must complete steps in a specific sequence

Wizard don'ts

In creating wizards, here are several mistakes you'll want to avoid.

Unclear purpose

There are two things that are essential to being clear about your wizard's purpose: a clear, concise wizard label on every screen and a brief explanation of purpose on the first screen. Believe it or not, some users may forget why they chose to enter a wizard if not reminded. At Homesite Home Insurance (see Related topics), many good wizard features were included, however the designers forgot to include a wizard label and a purpose statement on the first screen (see Figure 1). It's not apparent that the wizard will provide users with a homeowner's insurance quote. If users enter this page directly from a different site, they might have a difficult time understanding what this wizard will help them accomplish. A wizard label and a short explanation about the wizard's purpose up-front would remedy any potential confusion.

Figure 1. Home Insurance Quote wizard
Figure 1. Home Insurance Quote wizard
Figure 1. Home Insurance Quote wizard

Too many screens

Be careful not to break your wizard into too many screens. Users often get annoyed if they start to feel the process is too long, and may even abandon the wizard before finishing it. Keep in mind that wizards should make tasks easier to complete than traditional methods. If the wizard feels cumbersome, users will opt to do things the old way. In the newly published book, Designing Effective Wizards: A Multidisciplinary Approach (see Related topics), the authors recommend no more than 10 screens per wizard. Putting your wizard through a usability test will help ensure the number of screens is acceptable.

Long wizard screens

If a wizard requires users to scroll to enter data, its efficiency has been jeopardized. In a wizard, users should be able to enter data and select a navigation option (for example, Next, Back, or Finish) without scrolling. Long wizard screens may be a consequence of not breaking the wizard task down sufficiently into subtasks and sub-subtasks. To prevent long wizard screens, make sure each screen allows the user to complete a single subtask. If a subtask is particularly complex, consider breaking it down further into sub-subtasks, and creating additional screens.

No alternatives

A wizard should not be the only way for users to complete a task. Generally, a wizard should be an alternative to another, albeit more complicated, method for completing the same task. For example, in Microsoft Word 97, a Web page wizard is available to users who want a quick, easy way to create a Web page without coding (see Figure 2). More experienced Web page developers, however, may prefer to have more flexibility than the wizard allows, and may thus want to create Web pages using raw code. Microsoft would be doing a disservice to more advanced users if they only offered the Web page wizard.

Figure 2. Microsoft Web Page wizard
Figure 2. Microsoft Web Page wizard

Technical jargon

When writing your wizard content (instructions, field labels, etc.), keep your target audience in mind. Because wizards are often intended for novice users, remember that they may not be familiar with technical jargon related to the task. Avoid technical jargon and always write for the layperson.

No "Cancel" option

Sometimes a user enters a wizard and, for various reasons, decides not to complete it. To avoid frustrating users who are looking for a way out, include a "Cancel" button in the wizard interface. This button should typically be located near other wizard navigation buttons. The Homesite Home Insurance wizard did not offer users this flexibility (see Figure 1).

No exit warnings

When a user decides to click a "Cancel" button, or perhaps another navigation option that is not part of the wizard, it's a good idea to provide a warning if data entered up to that point will be lost. Some users may assume that they can return to the wizard later and start where they left off. (Hey, there's a good idea!) Due to the potential significance of losing data, a message should be presented to the user communicating the consequences of exiting the wizard and asking for confirmation.

External tasks

Wizards are best applied to tasks that can be completed in an integrated, sequential fashion. When users enter a wizard, they should not have to leave the wizard to complete a task. Retrieving information from another location within the site might be an example of an external task. External tasks are usually a sign that the task flow was not well thought out, or that additional effort was not taken to integrate the task into the wizard. An external task may also signify that the task does not lend itself to an integrated, sequential flow, in which case a wizard may not be the best approach. All tasks required to complete the wizard should be contained within the wizard.

Wizard dos

When designing your next wizard, there are also several good things you can do to ensure its effectiveness.

Minimize download time

People who use wizards are extremely interested in completing a specific task as quickly and easily as possible. When designing wizard screens, pay close attention to how quickly pages download using the lowest or most common Internet access speed. According to usability guru Jakob Nielsen, at 28.8 bps, a 1 KB file takes one second to download. Nielsen's research has shown that users begin to lose patience after 10 seconds (see Related topics). To help ensure that your users don't lose patience and exit the wizard, screen file sizes should be 30 KB or less. This means using graphics very conservatively.

Provide additional help

In the event that a user gets confused, or some aspect of the wizard doesn't work, it's a good idea to include easy access to additional help. This can be in the form of a telephone number that's visible throughout the wizard process. If your budget allows, readily accessible chat help can also be a good option. If you can't staff your phone or chat help 24 hours a day, a simpler option is to include context-sensitive help on each screen. This could be text that appears adjacent to the wizard, or in a secondary window when a user clicks on a help link. At the Homesite Home Insurance site, the designers keep things simple, but effective, by including a phone number on every wizard screen (see Figure 1).

Break tasks down logically

An effective wizard breaks down a task into subtasks and sub-subtasks, and sequences them in a way that is familiar and comfortable to users. An effective task breakdown is accomplished through task analysis. Task analysis is best conducted by observing real users performing the task in their work environment. This activity should be conducted before screen design begins. The outcomes of task analysis should include a task breakdown (in the form of an outline) and an information architecture for the wizard. The task outline and information architecture should be reviewed with users to ensure accuracy and completeness. For more information about task analysis methods, check out Task Analysis for User Interface Design, a great book by JoAnn Hackos and Janice Redish (see Related topics).

Inform users of progress

A wizard's boundaries should include a distinct beginning and ending point. Wizard users appreciate knowing where they are relative to these points. For this reason, many wizard designers incorporate a progress meter of some sort in the wizard interface. The progress meter informs users of where they are in the wizard process, providing them with a sense of how long it will take to finish. The progress meter may indicate an approximate or exact location. At Homesite Home Insurance, the designers have done a nice job of communicating progress in the wizard (see Figure 3). Homesite's progress meter tells users how many steps are in the wizard, which steps they've completed, and where they currently are in the process.

Figure 3. Homesite progress meter
Figure 3. Homesite progress meter
Figure 3. Homesite progress meter

Indicate required fields

A wizard is similar to a form in that users must enter text in field boxes and/or make selections with drop-down menus, radio buttons, or check boxes. As with online forms, be sure to indicate which items are required. Don't surprise uninformed users who do not complete required fields with error messages. It's best to be clear about what's required up-front. Required fields can be indicated with a special symbol (such as an asterisk) or by using a bold font. Avoid using color to indicate required fields as color does not always show up well on some monitors or to visually impaired users. Also, include a note at the top of every wizard screen that defines how required fields are indicated.

Limit navigation options

When users are working with a wizard, it's a good idea to keep them focused on the task at hand. For this reason, you may want to minimize the navigation options that are available outside of the wizard. At a minimum, you should include a link back to the home page for the site. Anything more than that could cause users to lose data if they inadvertently exit the wizard.

Summarize wizard data

Near the end of the wizard process, users should be able to review a summary of the data they entered on the previous screens. If the summary accurately reflects the information users want to submit, a "Finish" button should allow final completion of the wizard. Before clicking "Finish," users should be able to go back to previous screens, make changes, and easily navigate back to the summary screen. If the wizard process is fewer than 10 screens (a good thing), a "Back" button should be sufficient to enable changes to data. If the wizard process is longer, you might want to include direct hyperlinks back to specific screens.

Conclusion

While wizards should look easy to an outsider, designers and developers know the truth. There's a lot of planning, trial and error design, and complicated development that goes into wizard creation. As technology continues to encroach upon every aspect of our lives, there will be a growing appreciation for the relief wizards provide. While more research and shared experiences are needed, these dos and don'ts will help you begin to develop your wizard craft.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Web development
ArticleID=156144
ArticleTitle=Crafting a wizard
publish-date=09012001