Database Reference
In-Depth Information
Figure 1.1: A hand-drawn paper prototype of a screen from an application used to design filters for
scientific data.
After you create the prototype, you then conduct a usability test. You bring in a person who is
representative of the audience you and your team members agreed on. You ask this user to attempt
the tasks by interacting directly with the prototype—"click" by touching the prototype buttons or links
and "type" by writing data right on the prototype. One or two of you play the role of "Computer,"
manipulating the pieces of paper to simulate how the interface behaves but without explaining how it is
supposed to work. A facilitator (usually someone trained in usability) conducts the session while other
members of the product team act as note-taking observers.
You will quickly discover which parts of the interface work well and which are the trouble spots.
Because the prototype is all on paper, you can easily modify it right after—or sometimes even
during—each usability test. You can conduct several usability tests in just a day or two, and it doesn't
take long to see the patterns in the feedback you're getting. Thus, paper prototypes allow you to iterate
and improve a design quite rapidly based on input from real users, and this can all happen before the
first line of interface code is written.
The previous discussion makes reference to four roles: user, facilitator, Computer, and observer.
Figures 1.2 to 1.8 show these four people in action. (With the exception of the facilitator, there can be
multiple people in each role, especially observers. So this is a minimalist example, but still a realistic
one.)
Figure 1.2: Paper prototyping is a team effort. After creating the usability tasks, the product team
works together to generate a mock-up of the interface.
Search WWH ::




Custom Search