Database Reference
In-Depth Information
(You might refer back to
Chapter 3
, which discussed the designing, rendering, and coding aspects
of prototyping.) Don't forget to consider the time needed to document the design—at some
companies, the paper prototypes themselves form the basis for interface specifications, whereas at
others there's a need for more formal documentation.
"How long do spec reviews take?"
It can take several days to send an interface spec out for
review and get people's comments back—with a paper prototype, the walkthroughs (and the
usability tests) function as review activities in that they let you solicit and incorporate feedback from
key stakeholders. Consider the effect that paper prototyping might have on your process for
approving a design. Will it take less time for a person to approve a design if they have first
attended a couple of the usability tests? (Or on the flip side, will attending tests take longer than
the cursory reviews that person usually does?) Will a paper prototype help you get feedback from
someone who normally doesn't read specs?
"At what point do we start asking for user feedback, and how long do we allocate for
responding to it?"
To some extent paper prototyping may simply shift some activities that
normally happen late in the project (after coding is complete) into the earlier stages (before or
during the coding stage). For example, if your company plans long beta tests because that's the
first time you find out what your customers
really
need, perhaps you could use a paper prototype
early in the project to get customer feedback and then have a shorter beta test.
As you can see, it's hard to get an accurate answer to the question of whether paper prototyping takes
extra time because there are several factors to consider. For some teams it might, whereas for others
paper prototyping may partially replace activities they're already doing.
It is certainly possible to put too much time into a paper prototype—I've heard of people who spent
weeks preparing their prototype and an elaborate script for usability testing. If people are concerned
that paper prototyping requires an effort of this magnitude, the information in
Chapter 5
about planning
a usability study may be of use.
We Can Prototype Just as Well with _______
Some people may contend that a computer-based prototyping tool is just as fast and provides the same
benefits. This argument is really about efficiency, although it's rarely stated that way. To consider
efficiency, you have to weigh what you put into the technique with what you get out of it. Start by
estimating three things:
1.
Percentage of problems you'll find with a paper prototype.
Make a list of your most
important questions about the interface, then look at the
previous chapter
to see which
questions are answerable using a paper prototype. Estimate the percentage—is it 50%? 90%?
2.
Time needed for a paper prototype.
How long would it take to create a paper prototype, to the
nearest day? (Answers of 2 to 4 match my experience; answers greater than 5 are unusual and
suggest that too much effort is being spent on the prototype.)
3.
Time needed for a computer-based prototype.
How long would it take to create a working
mockup of the same functionality, including time to set up the test environment?
Now calculate what I call the
efficiency ratio
by dividing the percentage of problems found by the days
of effort. (For simplicity, testing a working version of the interface is assumed to find 100% of the
problems, although no method provides 100% accuracy. If your software prototype is incomplete in
some way, you might want to estimate a lower percentage of problems found for it as well.) Compare
the ratios you get—larger numbers are better because they indicate more problems found relative to
the amount of effort. Finally, consider how sensitive the result is to errors in your estimates. In most
cases the best course of action should be pretty clear-cut, but not always. Here are some examples.
Example 1
The cpselect tool from The MathWorks discussed in
Chapter 2
. Because most of their questions were
about how users would work with the tool and only a minority pertained to the visuals and interaction,
Search WWH ::
Custom Search