Database Reference
In-Depth Information
Creating the paper prototype takes anywhere from half a day to a week, depending on the state of the
design. Start by assuming 2 days and adjust the estimate depending on various factors—less time if
you're working mostly from screen shots and up to a week if it's a complete redesign or many people
have input. If you think it will take longer than a week, chances are you're overpreparing. Also keep in
mind that you don't need to prototype the entire interface, just enough to do the tasks.
Allocate time in half-day increments. Paper prototyping is not an activity that can easily be done in a
few minutes between meetings. Because of all the pieces, it takes a while to set up the prototype and
put it away. (Some teams don't like to leave their prototype spread out on the table overnight because
they're afraid that the cleaning crew will throw it away!) Most paper prototypes I've worked on have
been developed in three to four afternoons over a week or two. You may also want to reserve a
conference room for the prototype creation sessions and walkthroughs—you want a large surface to
spread out all the pieces.
Walkthroughs
Chapter 7 explains the purpose and method of conducting internal walkthroughs prior to the first
usability test. Walkthroughs are an integral part of the prototype creation process, so by setting aside
time for prototype creation you've also accounted for the walkthroughs. The exception is the last
walkthrough before testing—you may want to schedule that because it often involves a larger group
than the core team that created the prototype.
Debriefing Meeting and Action Plans
You may want to plan a short session immediately after each test to list what you saw and then make
changes to the prototype. Because that session is attended by the people who observed the tests, one
simple solution is to tack on a half hour to the testing time—if the tests will last 2 hours, tell people to
set aside 2.5 hours for each test they attend.
At the end of the usability study, after all the tests are complete, plan a debriefing meeting with the
entire product team to prioritize and discuss what you learned. People's memories fade pretty quickly
(my memory has a half-life of about 24 hours), so it's best to hold the debriefing as soon as possible
after the last test—I try to schedule it for the next day. It usually takes about 2 hours to prioritize the
issues, sometimes less, at which point you might continue into a discussion of how to address them, or
you might schedule a separate meeting for that. Once the debriefing meeting is over, there is probably
some additional work needed to document and/or communicate the results. Chapter 11 covers these
topics in more detail.
At this point, I return you to your regularly scheduled development process—whatever methods you
normally use to prioritize and plan your work, you should input the test results into.
Search WWH ::




Custom Search