by Saul Carliner

A wizard is software that performs tasks for computer users automatically¾prompting them only when they must make a decision. A wizard involves a structured series of dialogues that applies users’ responses to produce a result, such as installing software or writing a business letter. It is different from a tutorial and other online information in that it helps users accomplish a task, not teaches them how to do it.

A wizard is a performance support tool; that is, it supports users as they perform a task. Because the system performs some of the work, it can seemingly bring a user to a higher performance level in less time than conventional training methods. But the cost can be a dumbing down of tasks. Users perform tasks without understanding them and aren’t aware of the underlying decisions. As a result, users may not be able to perform tasks if the system is down.

You should use a wizard to build performance only when people can perform a task without knowing all of the steps. Consider these instances:

• When people perform rare tasks. Except for technical support people, most people install a software application just once. So, most software publishers turn the task into a wizard. The online instructions prompt users to insert diskettes and verify directory locations, and the system performs the rest of the tasks automatically.
• When people perform intimidating tasks. For example, credit approval can be an intimidating task, especially for someone who isn’t a trained credit analyst. Wizards can guide customer service representatives to enter data; the system reviews and approves the application. Wizards can also provide customer service representatives with suggested scripts for conversing with customers.
• When people can perform tasks now and understand the hows and whys later. You can design a wizard to give users the immediate feeling of success with a task and, when they are ready to learn more, provide other types of support or training to teach the underlying knowledge.

Top

Do your homework

When you choose to develop a wizard, you choose not to train; you choose instead to walk users through the steps. Because you have chosen not to train, you build mastery of the task into the wizard, not the users.

The design goal is to shield users from a process’s complexity. But you do let users make decisions that the computer cannot. For example, in a letter writing wizard, you would ask a user to enter the name of the recipient and choose the style of the letter. Only prompt users to make those decisions that can’t be made by a computer.

Before you develop a wizard, you should outline the human performance underlying it to determine which parts of the task the system will perform and which ones will.

The starting point begins at the end: determining the ideal human performance you want to achieve. For example, that might be customer service representatives entering orders without errors or home computer users creating pie charts of their household expenses.

To determine which tasks to convert to wizards, track usage patterns. For example, check logs of frequently asked questions--FAQs. Those questions reveal the most difficult areas for users and are the ones that may benefit from online wizards. Note that many tasks do not lend themselves to wizards.

Next, identify the types of users who have the most difficulty with the tasks so you can tailor the wizard to their needs. Then, conduct a task analysis--a process in which you observe expert users performing a task, track each physical and cognitive step involved, and create a flowchart of the findings.

Learning the steps for a cognitive task requires more effort than for a physical task. One way to do that is to record expert users speaking aloud while they perform a task. You can use the recording to re-create the process and verify the steps with the experts afterwards. Another way is to ask an expert to list steps in a task and then observe him or her in action to verify the process.

After you have identified all task steps, determine which ones can be performed by a computer and which ones require user input. For steps requiring user input, identify the possible choices. The choice that they’re most likely to make becomes the default choice.

Top

Interface it

After you have developed a process flowchart and determined which task steps will be performed by the system and which by users, you can begin developing the online components.

First, you should design what users see on the screen--the user interface. The user interface hides the complexity of a task. The most effective wizards present a task’s steps as a series of plain-language questions, not a series of input fields written in computerese. When designing wizard dialogue, consider these guidelines:

• Limit the intellectual load. Consider having only one question per screen. If the questions are simple enough, you might combine two or three questions on a screen.
• Limit the wizard to 10 questions. That’s a general guide, though; many tasks require more than 10 questions.
• Ask for information only once. For example, if a user has already entered an account number, you shouldn’t prompt to enter the information again. That can frustrate users and increase typographical errors.
• Use plain language and icons. Remember that you’re using a wizard because users aren’t necessarily experts. If you use technical jargon to prompt users, it should pertain to their workplace, not the programming. The best icons are intuitive and don’t require an explanation.
• Use a therapist’s sensitivity. When presenting choices, use such phrases as "Would you prefer...?" rather than "You should...".
• Provide on-screen previews. For example, to help users choose a letter format, you can show the different formats before they make a choice.
• Make sure users can complete a task without training. The point of a wizard is to avoid training for rare or intimidating tasks, not develop expertise.

Ask users to perform the task with a prototype to make sure that the wizard works. You can develop online prototypes but, if that’s not feasible, create storyboards and walk users through them in sequence. Consider asking usability engineers and user-interface designers to help you design a wizard’s online components.

Next, develop the underlying programming for the wizard. Although some trainers and instructional designers have the necessary skills, most rely on professional programmers.

Depending on the tasks to be performed and their complexity, a programmer may choose an authoring tool (such as Toolbook), a programming language (such as Visual BASIC or C++), a database programming and reporting language (such as SQL), or a combination of those tools. The choice depends on the software that a wizard interacts with. For example, if a wizard is to be used with another program, it should be developed with the same tool that developed the other program.

Use these guidelines when programming a wizard:

• Whenever possible, make sure that programs share data so users don’t have to re-enter it.
• Use well-chosen defaults.
• Many users don’t know what the choices really are. Wizards should prevent unintentional trial and error.
• Verify users’ choices.
• Especially make sure when users want to cancel or delete data; they may have pressed the wrong key.
• Develop to the lowest common technical denominator. Because the newest software provides the best capabilities, you might develop for it. Don’t. Users generally upgrade slowly and are more likely to have older versions. For that reason, test wizards on all types of hardware and software that users might have.

For people in the performance field, wizards involve a merging of instructional design and technical communication. Although instructional design methodologies can help you determine whether to use a wizard and the tasks it should handle, technical communication (also called information design and development) offers insights into developing effective user interfaces and communicating online. At its worst, that can mean turf wars between groups competing for the job of developing wizards. At its best, it can mean exciting interdisciplinary work and an expanded job-skills base.

Top

models | processes | techniques | resources on i.d. business and management | home

(c) Copyright. 1999, 2000, 2001, 2002. Saul Carliner. All rights reserved.