What Paper is (and Isn't) Good For - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 196

As Joel Spolsky said in Chapter 3 , the user interface is only the tip of the software iceberg—beneath
the surface are databases, networks, security, error handling, hardware, and more. The degree to
which these things are in place is depth. Whereas breadth relates to the percentage of functionality that
is represented, depth is the extent to which that functionality is fleshed out and, well, functional.
By depth, I mean not only the level of detail that's implemented but also its robustness. Say there are
10 options that users could choose from a drop-down list. One low-depth prototype might be hard-
coded to ignore what users pick; it assumes that a particular choice has been made. Another low-depth
prototype might allow users to pick any of the 10 options, but half of them cause the prototype to crash
because they are incompatible with other choices users have made. From the perspective of users who
choose one of those unsupported options, the net effect is the same: The interface doesn't do what
they told it. On the other hand, a high-depth prototype would have logic and error handling to gracefully
prevent, detect, or explain any combination of choices that didn't make sense. Thus, the high-depth
prototype would proceed in accordance with what users chose.
Depth turns out to be a key factor in usability testing because it affects the amount of exploration the
user can do. Experimentation is a part of learning, and depth (along with breadth) is the factor that
makes it possible. Without sufficient depth, the user must be constrained to walk a narrow path and/or
make numerous assumptions about whether the interface would behave as expected (not to mention
the time spent waiting for a crashed prototype to be restarted). In any case, there's a good chance that
important usability issues might be missed if the user isn't getting the full experience.
Look
The look factor is the easiest to determine by inspection and is probably what gave rise to the original
concept of prototype fidelity. Look refers to whether the visual aspects of the prototype accurately
represent the intended appearance, including fonts, colors, and graphics. Something hand-drawn would
obviously get a low score in the look department, and even printed-out color screen shots may earn
only a medium score if they look substantially different from how those same screens will appear on a
computer monitor—it's possible for a printout to look better than the same thing on a monitor, or vice
versa. Also note that software prototypes don't automatically earn a high score for look—they may use
different colors, graphics, spacing, and so on than the real thing. They just happen to have
recognizable fonts and straight lines.
When it comes to look, don't automatically assume that a higher score is better. As discussed in
Chapter 3 , a rough-looking prototype can encourage users and other stakeholders to respond in a more
creative manner. Especially in the early stages of a project, you might deliberately choose a prototyping
method with a rough look to get this benefit.
Interaction
Interaction refers to the way that the prototype handles the inputs and outputs with the user—are the
I/O methods simulated in a realistic manner? On a desktop computer, the input devices are typically the
keyboard and mouse, and the monitor is the output. For a piece of medical equipment, the user might
turn dials. For a handheld device, its weight and the spacing of the buttons might be important.
Time is an integral part of interaction, so consider things such as response time, cursor changes,
flashing lights, and animation. There also may be senses other than sight involved—some interfaces
use sound, and physical devices have tactile components. [ 3 ]
Note Some people confuse interaction with depth—the former refers to the methods used to
interact, whereas the latter is the degree to which the prototype responds as the real interface
would.
Comparing Prototyping Methods
Now let's consider four different methods of prototyping and how well they do at representing the
dimensions of look, similarity of interaction, and depth. Of course, these are not the only kinds of
prototypes—I chose them because they illustrate interesting differences. For this example, I'll assume
that the interface being prototyped is an e-commerce Web site, since that example is easy for people to
relate to. Table 12.1 shows a summary of how the four methods compare; you may want to refer back