Database Reference
In-Depth Information
The Final Walkthrough—the Usability Test Rehearsal
The usability test rehearsal is basically another internal walkthrough, but with a few extra elements
added. A rehearsal is not specific to paper prototyping—it's an important step in preparing for any
usability test. Ideally, the rehearsal should take place the day before the first usability test. It often
involves a larger group than those who worked on the prototype.
The purpose of the rehearsal is to make sure everyone (the Computer, facilitator, and observers) and
the prototype are ready for usability testing. The facilitator runs the rehearsal in a similar manner to how
he or she will conduct the usability test, but with several differences. Instead of focusing attention on
the user (who in a rehearsal is still one of the product team members), the facilitator's goals during a
rehearsal are as follows:
Familiarize observers with the prototype. It's hard to get much use out of watching a usability
test if you've never seen the interface before. That's especially true of paper prototypes because
they change rapidly; the design you're testing tomorrow may not have existed yesterday. Because
observers aren't allowed to talk during a usability test, encourage them to ask questions during the
rehearsal. Once they understand the interface and the test procedure, they'll be prepared to get
the most out of watching the usability tests. (Caveat: The observers aren't allowed to redesign the
prototype at the rehearsal. If they have ideas, they should write them down and save them until the
team is ready to make changes to the prototype.)
Collect people's questions. Let everyone know at the start of the rehearsal that you want to
gather all their questions about how well the interface will work and what real users will do. For
example, "Do users realize that they can sort by the column headings?" The test facilitator should
write down these questions with the aim of getting as many answers as possible during the
usability tests.
Estimate task timing. Although it isn't possible to say with any confidence, " Task 1 will take 14
minutes," timing the tasks during the rehearsal will give you a sense of how long it takes to
complete each task (assuming all goes well) and whether you have about the right number of tasks
to fill the time allotted for the tests. During a rehearsal there is usually some discussion among the
product team. To some extent, this discussion is a proxy for the amount of time that users will
spend thinking aloud or getting stuck in the usability tests.
Decide when you'll intervene. If there are doc/help writers on the team, they may be very
interested to learn if the material they've written is useful. But many users don't go to the help or
manual of their own accord. Discuss if and when the facilitator should intervene to suggest that
they look something up. You might also want to agree on at what point the facilitator should step in
and help users complete a task in the interest of moving on to the next one. (To an observer, it can
be nerve-wracking to watch a user struggle with a task that is meticulously explained in help, to the
point where that observer can no longer concentrate on what the user is doing. To forestall some
of this stress, it can be helpful to discuss when and how the facilitator will assist users. You may
also want to include this information in the Notes section of the task template.)
Note Because I have 10 years of experience facilitating usability tests, I no longer need to
have lengthy discussions about these things with the product team— they know that I am
aware of what they're interested in, and they trust that I'll get as much of that information
as I can. But if the facilitator and product team are unaccustomed to conducting usability
tests, they haven't established that level of trust yet.
Create a "game plan." It's not necessary to use the same tasks for each usability test—paper
prototyping allows some room for improvisation in the test structure depending what you're
learning. At the rehearsal, the facilitator should get a rough idea of which tasks are of greatest
interest to the developers and under what conditions it may be appropriate to skip or reorder tasks.
This is what I call a "game plan." An example of a game plan might be, "We'll do the first 3 tasks,
and then depending on how much time we have, either go on to 4 or skip to 5." Like its sports
counterpart, a usability test game plan is not a rigid structure but can be adapted depending on
circumstances. For example, if a team member is very interested in task 5 but she can attend only
two of the usability tests, in those sessions you might decide to do task 5 earlier to ensure she'll
Search WWH ::




Custom Search