Usage
Use when the user needs to perform a task or a goal that dictates more than one step.
- An example is adding an image to a website which can include uploading the image and cropping the image; the image cannot be
cropped before it is uploaded to a server. Use when the user needs to
perform a complex task consisting of several dependable sub-tasks.
Use when the user needs to input complex data into a system that is easier for the user to comprehend parting the process into multiple
steps.
Use when the user needs guidance: the user wants to achieve an overall goal, but may not be familiar in the steps needed to reach the
goal.
Use when the steps needed to reach a final goal may vary due to decisions made in previous stages.
Use when the user lacks necessary domain knowledge.
Use when the user must complete steps in a specific sequence.
Solution
The task of inputting data into the system is parted into multiple
steps. Each step is presented to the user one at a time.
The user should be presented with information about the steps that
exist and which are completed.
The Wizard pattern is very similar to the Steps Left
pattern. The difference
between the two is the focus. Where Steps Left is focused only on
explaining the steps of a process, the Wizard pattern is about
parting dependable sub-tasks needed to perform a complex goal into
separate steps.
The Wizard pattern is also different from the Steps Left
pattern in that the steps
needed to perform a goal can vary depending on the information
inputted in earlier stages. In this way, the Wizard pattern
separates itself from being merely an visible aid for the user.
Buttons
Basically, a wizard is a series of screens or dialogue boxes walking
users through the completion of a task. Each screen asks the user to
input information by either making selections or filling in fields.
After inputting data, users navigate through the wizard by clicking
navigation options like “Previous” and “Next”. At the final step users
click “Finish” instead of “Next”, which thus indicates the completion
of the wizard.
It is also practice to include a “Cancel” button on all screens that
will lead the user back to where he or she came from. Typically, a
“Cancel” button is located near other navigation buttons, but in a
position that clearly separates the button from the “Previous” and
“Next” buttons. Furthermore, it is also good practice to provide a
warning if data inputted up to that point will be lost clicking the
“Cancel” button. It is fair for to assume that the user expects that
he or she can return to the wizard later and start from where they
left off3. In order not to frustrate the user more than necessary, the
consequences of exiting the wizard should be communicated.
Wizards are meant to be fast and easy. For this reason, it is a good
idea to keep the content of a screen as well as its navigation above
the fold.
Keep the purpose clear: explain
Keep the wizard’s purpose clear on every screen by placing a clear and
concise label on every screen. Optionally accompany the label with a
brief explanation of the wizard’s purpose on the first screen. This
will help users remember why they entered the wizard in the first
place and how they will benefit from finishing the wizard.
Use plain language
Users of a wizard aren’t necessarily experts, why you should refrain
from using technical jargon to prompt users. The language used should
fit in to the user’s frame of reference5.
Summarize choices
It is good practice to present a summary of choices made throughout
the wizard to the user near the end of the wizard. This will allow the
user to review and double-check inputted data before the final
“Finish” button is clicked. In the case the user wishes to change the
data entered, he or she should be able to navigate back to the given
page where the date was entered. If the amount of steps in the wizard
is greater than 8-10, it is a good idea to provide links directly to
the screen of the data input.
Good defaults
A wizard is a perfect place for using Good
defaults. Most wizard
users are not familiar with the task they are performing and is thus
likely as unfamiliar with good values for the choices they are asked
to make.
Rationale
By separating complex tasks needed to achieve a goal into several
steps, the process of inputting data can take several different
directions depending on what input is entered.
The complex task of inputting large amounts of dependable data can be
adjusted and streamlined to fit the decisions of a user throughout a
process. In the context of decisions the user makes in each step,
unnecessary steps can be cut out and important steps can enter into
the focus.
In a system with many variables, a user can reach many goals
manipulating these variables in different ways. The Wizard pattern can
be used to group such variables into separate goals. This will convert
the task of completing a complex goal from requiring multiple actions
from the user into being a coherent process.
When users are forced to follow a set of pre-defined steps they are
less likely to miss important aspects of a process and will thus
commit fewer errors.
Minimum of training
Wizards are often made for the untrained user. For this reason, make
sure your wizard can be completed without training. A rationale behind
using a wizard is to avoid training for rare or intimidating tasks –
not to develop expertise5.
Discussion
Using the Wizard pattern helps the user perform a complex task, but
can at the same time effect the performance time of the task.
An effective wizard breaks down a complex tasks into sub-tasks and
possibly sub-sub-tasks. Sub-tasks are through task analysis broken
down and sequenced in a way that feels familiar and comfortable for
the user. Such task analysis is conducted before screen design begins
and is best done observing real users performing the task in their own
work environment. The output of the task analysis is an outline and
information architecture for the wizard.
Keep the amount of screens low
By breaking a task up into many screens, there is a chance to loose
the user. If the process of finishing the wizard feels too long, the
user often gets annoyed and possibly abandons the wizard before
finishing it.
Be careful not to make each step too long
While the amount of screens should be limited, you should not
always keep the amount of screens to a minimum. When a screen of a
step in your wizard grows to a height that does not fit into a regular
screen solution, there is a risk of annoying the user and making the
wizard tiresome to finish as it forces the user to scroll to enter
data and navigate back and forth. Consider breaking such steps up into
two or more screens.
To find out whether you have hit the right balance between a low
number of screens and short screen heights, put your wizard through a
usability test. It is hard to define other means of checking when a
good balance between the two has been found.
Allow alternatives to using the wizard
A wizard support users performing a task by lowering the learning
curve. It can seemingly bring a user to a achieve a higher performance
in less time than without the wizard. It however comes with the cost
of dumbing down the task as users perform tasks without understanding
them and being aware of the underlying decisions5. The result is users
not being able to perform a task if the wizard is not available as
well as not being able to fine tune decisions made by manipulating
other parts of the system.
A wizard should not be the only way for users to complete a task, but
merely an alternative to another more complicated method of completing
the same task. Use a wizard for allowing the untrained user to get
started quick and let the more experienced users, who prefer more
flexibility than the wizard allows, use the more complicated method.
