Task Design - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 98

Step 4: Create a Task
This is the step that's hardest to describe in concrete terms. In essence, take your two lists (user goals
and your questions) and pick a user goal that covers one or more of your most important questions.
Then turn it into a task by asking, "What's a specific example of this?"
For each task, fill out the following template (which is available at www.paperprototyping.com ).
Task #: < Task Name >
Goals/output:
Inputs/assumptions:
Steps:
Time for expert:
Instructions for user:
Notes:
Task name and number. Give each task a brief descriptive name and a number. The name helps
you remember what its purpose is, and the numbers are useful in usability testing because you can
ask the observers things such as, "Shall we skip 3 this time and go right to 4?" without discussing
the content of the tasks in front of the users.
Goal/outputs. What will users have accomplished when they're done with the task? Is there a
tangible output? How will they know the task is complete? What might the users do to be sure?
Inputs. List all the information or resources—tangible and intangible-that a user would need to
complete this task. Examples include a valid log-in, business policies, physical objects such as a
textbook or a credit card, file names, and so on. Real users may have some of this information in
their heads—in your usability task you might have to provide this information. For example, a
network administrator probably knows the network configuration by heart, but for your task you'd
need to create a network schematic with relevant details, such as server names and IP addresses.
For the inputs, outputs, and everything that happens along the way, you'll need to have consistent
data that reflects a realistic scenario. For instance, if users enter information on one screen that
appears in a report later, the report should match what users entered to avoid confusion (I talk
more about creating data in the next chapter ). During task design, start thinking about realistic data
that you could use for the task.
Assumptions. Assumptions are the conditions and prerequisites that are in place at the start of
the task. The assumptions depend on what you want to learn from the task. For example, if a task
explores how users recover from an error caused by a duplicate record, your assumptions include
the condition(s) that cause the error to occur, such as, "An employee with the same name already
exists in the database." Often, your assumptions will emerge when you start doing walkthroughs,
so you don't have to nail them all down in the task design session—you can add more later. In
practice, I sometimes combine assumptions with inputs because the distinction between them isn't
crucial; they're both things that we need to consider while preparing the prototype.
Steps. Write down the steps you expect the user will go through in completing the task. This helps
you identify the prototype pieces that you'll need to create. Writing down the expected steps can
also be helpful if there will be observers who aren't as familiar with the interface as you are.
Keep the steps mostly at a screen level—no need to list every field on the order form, just say
"order form." Don't worry about exact terminology because these steps are just for your benefit in
preparing the interface. The user won't see these steps, only the task instructions that you'll write
later. Some tasks have multiple paths that lead to success, so jot down any variations, such as
"Search OR navigate to lawn & garden page." Put optional steps in parentheses, such as (Review