Case Studies - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 22

Chapter 2: Case Studies

Overview

So what is paper prototyping good for? In a nutshell, it lets you create and refine an interface based on
user feedback before implementing it. This chapter contains several real-world examples where paper
prototypes provided that important— and often surprising—feedback.

To illustrate that paper prototyping works for a variety of interfaces, I've chosen a software application,
a Web site, a Web application, a telephone display, and a small touch screen. In each example, the
product team created a paper prototype of the interface before a working version was available and
tested it with about a half dozen users.

You'll notice several types of findings from these case studies:

1. Usability issues. This broad category contains all the sorts of things you'd probably expect to

find from usability testing—confusing concepts, poor terminology, lack of feedback, layout
problems, improperly used widgets, or any other situation in which the users can't get the
interface to work the way they need it to. But usability issues are just the beginning.

2. Missing (or misspecified) functional requirements. It's common for users to have some

needs that the product team isn't aware of at the start of the project, or the team may have a
mistaken assumption about what functionality will satisfy a user requirement.

3. Preference for one design alternative. Sometimes there are different ways to provide a

function and it's a coin toss to developers which one is easier to implement (but instead of
tossing that coin, they debate it ad nauseam in meetings). Users, however, may have a firm
preference for one or the other, which will show up pretty readily in usability testing.

4. Priorities. No company has unlimited resources, so it's important to separate the gotta-haves

from the nice-to-haves. Occasionally a paper prototype will reveal functionality that isn't as
important as the team had thought—a feature that draws a ho-hum response from users can be
moved lower on the priority list or even dropped, thus saving work.

5. Issues outside the user interface. Interestingly, paper prototypes can reveal some issues that

one might think of as being outside the scope of the user interface, for example, the credibility of
the company or the implications of using the interface in a social setting. When the interface and
tasks are realistic enough, test participants start extrapolating to their own environment and thus
they can anticipate problems. (Caveat: Not all the problems—some problems can be found only
in real-life use and won't show up in a usability lab, even if you test the released product.) These
issues can result in changes being made in the interface or elsewhere, such as marketing or
training materials.

You'll also see that there's quite a variety in the scope of issues revealed by these case
studies—everything from high-level strategic issues ("Are we building the right thing? Will the market
accept this product?") to low-level and specific ("Does this control offer the right degree of
magnification?"). In my experience, it's common for paper prototype tests to turn up both high-level and
low-level issues, so these examples are pretty typical.