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

privacy policy).
Time estimate for expert. Estimate how long it would take an expert (someone on the core team)
to complete the task. Ignore any time needed for the system to do its processing and focus on the
time spent entering data and clicking buttons. Some tasks, such as composing an email, require
time for thinking or creative effort, so allow time for that. In the next step of the task design
process, I'll explain how to use this estimate to decide when you've created enough usability tasks.
Instructions for users. Don't write the instructions for the users when you're filling in the rest of
the template. Although task design works well as a group activity, writing the instructions can be
done by one person after you've drafted your set of tasks. The following examples include the
instructions, but keep in mind that they were written after everything else in the template.
Notes. The notes section might have several types of information, including the reasons why you
created the task, how you'll conduct it, specific things to watch for, and questions to ask users after
the task is complete. Information to include in the notes varies depending on what's being tested.
Write down whatever information you think will be useful to have on hand during the usability tests.
Give copies of the completed task templates to usability test observers because this information
helps them get more benefit from watching the tests. It's also quite helpful to the test facilitator.
Because task design is a group activity, you may want to draft each task on a piece of flip chart paper
or a whiteboard. Ask someone at the meeting to fill out the template on a laptop as you go so that you'll
also have it in electronic form.
Examples of Completed Task Templates
The following are examples of completed task templates that I've used in paper prototype usability
tests. Although these tasks came from very different interfaces, you'll note the following things they
have in common:
The steps are described at a fairly high level, often tersely. These are intended for the development
team, who knows what they mean.
Each task would take an expert only a few minutes to complete.
The length of the instructions given to users varies depending on the amount of background
information the user needs to understand and complete the task. (Note: I have not yet explained
how to write task instructions; that's coming in step 6.)
For some tasks, there are detailed notes, but for others there are none.
Although three of the four examples happen to be from Web applications, tasks for other types of
interfaces look much the same. In fact, when you are thinking in terms of goals and instructions for the
users, the type of underlying technology shouldn't matter much, if at all. It comes into play only when
you're looking at the steps, and to some extent the inputs and outputs. When the goal and task
instructions are free of any references to technology or functionality, it's usually an indication that you've
been successful at keeping your focus on the users rather than getting bogged down in implementation
details.
Example 1: Web Application for Online College Courses
Background: This application is used by college students. When they purchase a textbook, students
get access to the online version of the topic and additional course content provided by the instructor.
For a new book, this access comes in the form of a card containing a code. This task explores what
happens in the case of a used book. Because the code can't be reused, the student must pay
separately for access to the online materials.
Task 2: Used Book