Database Reference
In-Depth Information
Figure 5.1:
This graph from
Nielsen and Landauer's work (1993)
is often cited as the reason why
you only need a handful of users—there's clearly a point of diminishing returns in testing with
additional users.
Fortunately, with a paper prototype, the tasks are naturally somewhat constrained because you're only
prototyping a portion of the interface and/or you're preparing the data the user sees. Thus, paper
prototype tests tend to fall under the conditions of the Nielsen and Landauer study. Practically
speaking, I find that after three or four tests I can usually see the patterns in what users are confused
about and bothered by. There is no guarantee that you'll uncover all the problems, but once you have a
few hours' worth of observations, it's time to step back and digest what you've learned.
So I suggest that for your first usability study, you plan no more than four to six tests. If you are using
co-discovery (two users at a time, as explained in
Chapter 8
), you might schedule four 2-hour tests (for
a total of eight users), or if you would rather test with one user a time, you could plan six 1-hour tests.
With either of these schedules you can complete the testing in 2 days. Keep in mind that you can
always do more tests later if you want.
Spacing of Tests
It's important to leave time between tests to review what you've learned and make changes to the
prototype. If you're accustomed to conducting nonpaper usability tests, you may be in the practice of
scheduling an entire day's worth of tests back-to-back, but this doesn't work as well with paper. I
suggest a maximum of 4 hours of testing time per day, with a minimum of 2 hours between tests.
The schedule I've most often used is to hold usability tests from 10 AM to noon and from 2 to 4 PM on
two consecutive days. That's a total of four tests, and with co-discovery that's eight users. Of course,
testing can be spread over a longer period if the team expects to make substantial changes. In that
case, I might leave a day in between the 2 days of testing. I rarely allow more time than that because
usability testing with a paper prototype is an immersive activity. If you stop for too long, you'll lose
momentum.
Estimating the Other Activities
Once you have scheduled the usability tests, you'll want to schedule the activities that precede and
follow them.
Task Design
The
next chapter
discusses task design in detail. I've found that task design is often the most difficult
activity in a paper prototype usability study because it tends to expose missing or conflicting
assumptions that team members have about the product and what users will do with it. Thus, from a
planning perspective I like to set aside a minimum of 3 hours (per user profile) to design tasks—and be
prepared for it to take up to twice that long, especially the first couple times. It's also a good idea to
have the product team review your tasks; thus, you may want to plan some time to modify them.
Creating the Paper Prototype
Search WWH ::
Custom Search