Database Reference
In-Depth Information
Communicating and Documenting the Results
It usually isn't practical to write a detailed report of paper prototype test results—in 10 years as a
usability consultant, I've never done a detailed report for a paper prototype, although I have
occasionally written such reports for more formal usability studies. However, it's important to
communicate your findings to people who couldn't be there and/or will need the information later. Once
you're ready to move into the implementation phase, the paper prototype contains a lot of information
that you may need to document in some way. There's additional information in the Computer's head
about how the interface behaves, and you don't want to lose that either.
This section contains several ideas for communicating the results of a usability study. They differ in
their formality, the situations in which they're useful, and the effort needed to do them. You'll need to
consider the particulars of your company culture in deciding which one(s) are right for you.
Top-10 List
The first thing I do after the debriefing meeting is to take the prioritized list of issues and create a short
summary of the top issues. Typically I'll write one to two paragraphs about each issue that summarize
our discussion from the meeting. The resulting report is usually no more than two to three pages; when
I do it in email it's even shorter. For some product teams this is all the reporting that's needed.
Methodology Report
You might find it helpful gather all your methodology-related documents (user profile, screener, tasks,
and so on) into one document to make things easier for next time. Because " methodology report "
sounds overly stodgy, I sometimes I call this the "paper trail" report. Its primary purpose is to keep you
from reinventing wheels because user profiles and tasks can often be reused in subsequent usability
studies. Alternatively, you might simply collect all these documents into one (real or virtual) folder for
safekeeping.
Highlight Tape
A highlight tape uses clips from the paper prototype tests. I rarely make highlight tapes because they're
time-consuming, and they're usually unnecessary if you can get people to observe the tests. So
consider this a technique to use only on rare occasions (for example, to accompany a presentation
you're giving to 30 co-workers in another city) and make sure you've obtained the users' consent for
that purpose.
Walkthrough Video
A walkthrough video can be an efficient means of summarizing what you learned from a paper
prototype usability study. A walkthrough video is especially useful when the development team is in
multiple locations. I've worked on several projects where the design part of the team was in Boston but
the developers were in California, Russia, or Israel. Unlike a highlight tape, a walkthrough video is
scripted and it shows a member of the development team instead of real users.
To make a walkthrough video, first jot down what you want to cover—how users reacted to various
aspects of the interface, what you changed, how successful those changes were, and so on. Then turn
on the video camera, focus it on the prototype, and start doing a show-and-tell explanation of what you
learned. (If the development team is located in another country, consider making the tape in their native
language.) There's no need to do everything in one take, so stop the camera whenever you need to
gather your thoughts. A typical walkthrough video is 10 to 15 minutes long and can be created in an
hour or so.
Interface Specification
To some extent, a paper prototype itself is a kind of an interface specification because it is a collection
of screens. But you might need to tie the images together in a way that shows the sequence, with
Search WWH ::




Custom Search