Database Reference
In-Depth Information
Chapter 6: Task Design
Task design is one of the most important aspects of usability testing. You don't just watch users do
whatever they want with the interface; you create specific tasks that cover what you want to learn. A
good task is like a spotlight that illuminates your interface, showing you the parts that work well and the
issues that get in users' way. A good task provides reliable data about key issues so that you get the
most from your usability study. But a poor task can mask problems or even turn up false ones. For
example, if you ask users to do something that they would never do in real life and they fail, it's difficult
to tell whether the interface really has a problem or if you've created an artificial one.
As important as task design is, it isn't easy to do it well. I think task design is probably the hardest part
of usability testing, and even after 10 years I'm still learning. This chapter shows you what has worked
for me and helps you avoid some common pitfalls.
Characteristics of a Good Task
So what makes a good task? A good task has the following characteristics. (Except as noted, this
discussion applies to tasks used for any type of usability testing, not just paper prototypes.)
Is based on a goal that matters to the user profile you've chosen.
Covers questions important to the success of your product and business.
Has appropriate scope—not too broad, not too specific.
Has a finite and predictable set of possible solutions.
Has a clear end point that the user can recognize.
Elicits action, not just opinion.
I'm going to discuss the first two characteristics—users' goals and your questions—in detail when I
describe the process of creating tasks. For now, suffice it to say that if a task doesn't have the first two
characteristics, it is likely to give you misleading information or waste your time.
Has Appropriate Scope
The scope for a task should be large enough for the user to achieve a realistic goal and to answer one
or more of your important questions. Typically, tasks of this scope take anywhere from 5 to 30 minutes
to complete with a paper prototype.
If you're new to usability testing, your first inclination may be to test one screen at a time. Screens are
designed one a time, but this isn't the best way to test them—you won't uncover the broader issues
that arise only when the user sets out to accomplish something. For example, there may be an
important function that users need. If you just show them one screen that doesn't contain that function,
they may assume that you've provided it elsewhere, when in fact you aren't even aware that it exists.
Sometimes your co-workers can review a screen—this is sometimes called "hallway usability"—and
spot your more egregious blunders ("Dude, there's no way to delete a record"), but real users have a
hard time at this because they're not used to thinking like designers. Unless they've read the functional
spec, they don't know all the features that are supposed to be available.
Has a Finite and Predictable Set of Possible Solutions
If you had an entire working interface at your disposal, you might not be concerned about having a finite
set of solutions, but when you're using paper you have to make all the prototype pieces to support what
the user might do. Thus, you may want to introduce some constraints into your task for the purpose of
limiting the amount of preparation you'll need to do.
For example, if you were testing a working version of a gardening site, you might have a task that says,
"Last year, raccoons ate the crocus bulbs you planted. Are there any bulbs that don't appeal to critters?
Search WWH ::




Custom Search