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

What Paper Prototypes Will Likely Find (Depth Issues)
Looking at Table 12.2 , there are several rows that have Depth as one of the factors. As a
generalization, these are the types of questions that paper prototypes are well suited to answer.
Concepts and Terminology
Unclear concepts and confusing terminology are common—I don't think it's an exaggeration to say that
I've seen these types of problems in every interface I've ever tested. Sometimes even one ambiguous
word can prevent users from completing a task. For example, one user who was testing an e-
commerce site refused to buy a cordless drill because it was described as a "kit" and he couldn't figure
out what the kit included besides the drill. To probe problems pertaining to concepts and terminology,
you need actual wording and often the supporting help or documentation as well, and these are depth
factors. On the other hand, look and interaction usually aren't as important; if users don't understand
the meaning of a field label or they need to see an example, this will be apparent regardless of whether
the label is handwritten or typed.
Navigation, Work Flow, Task Flow
Breadth is an important dimension in determining whether users can navigate the interface or perform
their work tasks because there is often more than one correct path, as well as a large number of
incorrect ones. One way to think of it is that you should provide enough of the interface to confuse
users. (More properly, the goal is to ensure that users aren't confused, but if you make a simplified
version of the interface you can't tell when you've accomplished that goal.) To evaluate navigation, it is
essential for users to have the ability to go where they want next, which may or may not match the path
you envisioned when you created the interface. Depth is important because users sometimes step off
the correct path and it's useful to know whether the interface succeeds in guiding them back onto it. Or
sometimes the users' path is different but also correct—with a low-depth prototype, you may not be
able to watch them do it their way.
Content
Content issues pertain to interfaces where users seek information and make decisions based on it (as
opposed to an interface used primarily for data input). Similar to concepts, content questions are
primarily a function of breadth and depth. In usability testing, if you want to watch users make
decisions, it's often important to show them the real content, not greeked or approximated by wording
such as "guarantee goes here." As discussed in Chapter 7 , it may be easy to draw the content by hand
or print it out, so a paper prototype doesn't have any inherent advantage or disadvantage over other
methods when it comes to content—it depends mostly on where your content is coming from.
Sometimes you need breadth to understand content issues. If an interface or its content is very
complex or large in scope, a paper prototype may fall short of the degree of realism you need. For
example, a music Web site might offer thousands of albums—a paper prototype of the site has no
realistic way to represent how all this content would appear to users or how they would interact with it.
Although you might learn many useful things from paper prototype testing, there may be some
questions you can't answer, such as whether users in real life would prefer to search or browse to find
music.
To what extent is look part of content? If you're selling flowers online, color is indeed part of the content
because users care whether the roses are red or yellow. But if you're selling life insurance, color has
little to do with the content of the site, although it will undoubtedly be present in the graphic design.
Similar logic could be applied for every aspect of your interface's visual design—the more of these
factors that pertain to the content, the more concerned you're likely to be about the look factors that are
discussed later in this chapter.
Documentation/Help
The issues for documentation and help are similar to those for concepts and terminology, which is