Preparing the Prototype - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 125

Internal Walkthroughs
An internal walkthrough as I've defined it is an activity that helps the product team prepare to conduct
usability tests with the paper prototype. A walkthrough is similar to a usability test in that you have a
prototype and tasks, but in this case there are no outside users. Instead, one team member acts as an
"expert user," performing the task the way the product team expects it to be done.
A walkthrough is a practical exercise that helps the team:
Identify parts of the prototype that still need to be created.
Prepare for different paths the user might reasonably take (correct or otherwise).
See how the interface is intended to work, which is especially useful for those creating
documentation or training or who are new to the development team.
Give the Computer practice in manipulating all those pieces of paper.
Identify issues pertaining to technical feasibility. Typically, these are researched after the
walkthrough.
You should hold your first walkthrough as soon as you think you have most of what you need to get
through at least one of the tasks. Depending on the size of the team working on the prototype, it may
be easier to wait until you're ready to walk through all the tasks at once, or you may want to tackle them
one or two at a time. This also depends on the complexity of the interface and the confidence you have
in the design. If you're creating something new, it's often useful to put the pieces together sooner rather
than later, just to make sure everything hangs together.
How to Do a Walkthrough
To hold a walkthrough, you'll need a table that's large enough to spread out the prototype. Assign
people to the following roles:
Computer. The person who organizes and manipulates all those bits of paper (may be more than
one person).
Expert user. A product team member plays this role, performing the tasks as an expert (someone
who understands the interface) would be expected to do. It's not part of this role to make bizarre
mistakes or other radical departures from the norm—leave that for the real users!
Scribe. This person writes down all the missing pieces, issues, and questions that come up. It's
not always the best use of time for the entire team to discuss each issue on the spot and come to
a decision. The scribe makes a list so that these things can be addressed after the walkthrough.
On small teams, the scribe role may be combined with any of the other roles.
Facilitator. Strictly speaking, a walkthrough doesn't need a facilitator, although it doesn't hurt to
have a designated person lead the session and make sure it doesn't digress too much. Whoever
plans to facilitate the usability tests should attend some walkthroughs in preparation; walkthroughs
are a great way to become familiar with the functionality and behavior of the interface. For new
facilitators, it's also an opportunity to practice.
Naturally, other members of the product team can also be present to help make missing prototype
pieces, identify potential issues, learn about the interface, or simply to get a better understanding of
paper prototyping.
As the expert user walks through the tasks, questions and issues will arise and the scribe should write
these down along with missing prototype pieces. At the end, the scribe reads the list and team
members decide who will do what before the next walkthrough. Agree on the time of the next