Database Reference
In-Depth Information
Kickoff meeting
When starting a paper prototyping project, get everyone together to discuss the goals of the testing and
the method. Here's a typical agenda for this meeting:
Provide an overview of activities
Discuss risks and concerns
Create a user profile
Determine the schedule
Provide an Overview of Activities
The first time you do paper prototyping or even usability testing, it's natural for people to have questions
about these activities. You might print out a version of
Table 5.1
and take it to the meeting. You might
even make a paper prototype of an application everyone is familiar with, just to show them what you're
talking about. Paper prototyping is one of those visceral things that can be hard to explain, but
everyone knows it when they see it in action.
People who are not part of the core team may wonder which activities they need to be involved in. I
recommend that they attend the following:
At least one walkthrough,
preferably the last one before testing begins. People get more out of
observing tests if they're familiar with the prototype beforehand.
At least two usability tests.
Mathematically speaking, you can extrapolate in any direction from a
single data point. If someone observes only one usability test, he or she may prematurely conclude
that the interface has a problem and that other users will have the same difficulty (or conversely,
that this user represents an outlier and that there really isn't a problem with the interface). But if
that observer watches another usability test, he or she will see similarities and differences, which
provides a better perspective on reality. Even if some people can observe only one test, that's still
much better than nothing—just caution them that what they see may not be typical and that they
should compare their observations with what happened in the other tests.
The debriefing meeting.
Because this is when the issues are prioritized and discussed, it's a
good way to find out what happened at the other tests. If there will be a report of the findings, you
might suggest reading the report as an alternative to attending the debriefing meeting, although the
downside is that the person won't be involved in prioritizing the issues.
Discuss Risks and Concerns (Finding the Rattlesnakes)
As the saying goes, it's not the rattlesnake you see that will bite you. The real value of paper
prototyping comes from its ability to point out problems early in the development process, while it's still
easy to avoid them. Thus, you should design your usability tests around whatever aspects of the user
experience you are most worried about (or know the least about). This is called
risk management.
This kind of thinking is backward from how software is often developed. To have a solid base of code to
build on, developers often start with the pieces that are well understood, just to get something running.
Aspects of the design that are still up in the air are postponed until later, thus providing ample cover for
the rattlesnakes. But because paper prototypes don't depend on functioning code, they allow you to do
the opposite—start with whatever you have the most questions about, mock something up, and get
user feedback. As soon as you have a handle on a particular issue, you can turn your attention to
whatever's next on your list of things to worry about.
Paper prototyping is an excellent tool for risk management because it helps you clarify what you do and
don't know about how well your interface will work, and it can help the team make important decisions.
Ronnie Thomson, Director of Engineering, describes Centra's prototyping experience before the first
release of their Web application Symposium: "There was an undercurrent of doubt about whether we
Search WWH ::
Custom Search