Skip to main content

Six Signs That You Should Use Paper Prototyping

December 23, 2003

{cs.r.title}






This time of year, there's plenty of leftover wrapping paper sitting around.
Why not put it to good use? If you create interfaces, you may have heard of
paper prototyping. It's a technique that lets you mock up, test, and refine
a design -- totally on paper -- before you write a line of code. Figure 1 shows
an example of a paper prototype screen, and the second half of this article
has more details about the method. But first, we begin with some signs that
paper prototyping might be right for your project.

Sample
Figure 1. Here's what a paper prototype screen looks like, using the familiar
Page Setup dialog box as an example. Although crude, even a hand-sketched interface
is usually good enough to get meaningful feedback from users.

When to Use Paper Prototyping

Paper prototyping lets you conduct informal usability tests with real users
early in the project, before the design is cast in concrete code. Here are six
signs that your project could benefit from paper prototyping.

Sign 1. There are many different ideas about the design.

Maybe you sit in meetings arguing about how users will use the
interface. Maybe you've got a radical idea that could result in a
slick and elegant interface ... or land you in the usability hall of shame,
if users can't figure out how to use it. Maybe there are different
approaches to the design, and you aren't sure which is best.

In practice, there will be times when any of the possible approaches
will prove to be good enough for users, and you might as well flip a coin.
Other times, they're all fundamentally flawed due, to some factor
you're not aware of yet. In either case, it's a waste of time to
debate the designs. Instead, you need to get user feedback.

Paper prototyping makes it easy to sort the wheat from the chaff. Start
with the design that's easiest to implement. Make a paper prototype of
it and have a few users try it out. If the simplest design works (maybe
with a few tweaks), then there's no reason to make it more
complicated. On the other hand, if you learn that the simplest design
isn't going to cut it, then prototype and test a more elaborate
version.

Building it with paper will tend to keep you focused on keeping the
interface simple. Consider the implications of starting with the simplest
design -- you're less likely to build things that users don't need.
I've often wondered what percentage of development effort is spent on
functionality that users don't really care about or aren't even
aware of. It's kind of depressing to think about! But with a paper
prototype, the opposite happens -- you can get reassurance early on that
users will appreciate what you're building.

Sign 2. You find yourself defending a particular design.

Say you spend three weeks coding a working prototype. You show it to the
marketing guy, and he immediately finds something he doesn't like. Or
you show it to your project manager, and she can't figure out how to
use it. Because you put in all of that work, you're likely to feel
frustrated. It's understandable that you'd be tempted to defend
your design instead of responding to the issues.

Paper prototyping helps you avoid this no-win situation. Because it
requires relatively little effort, compared to coding, a paper prototype
makes it easier to let go of designs that aren't working. If you only
spent a couple hours on a prototype and someone finds a problem, you can
respond more objectively because you don't have a big investment in
the design.

Sign 3. There are parts of the design you're unsure about.

There's always a temptation to start the design process with the
parts you're more sure of, and defer the challenges and unanswered
questions until later on, when you believe you'll have a better
overall understanding of how the application or system will work. I know I
fell into this trap many times when I was a programmer, especially when I
was trying to get something up and running. (Of course, this may be an
indication that I wasn't an especially good programmer!) But, as the
saying goes, the rattlesnake you see is not the one that'll bite you.
The earlier in your project that you can find the proverbial rattlesnakes,
the better.

Or you might assume that you understand something and later discover that
you don't. I learned this lesson the hard way years ago, when I was a
software project manager at a building controls company. We were
developing a configuration application to be used by our company's
field engineers. The application included a set of reports that showed
information in the various databases. We had left the reports until late
in the project, under the assumption that they wouldn't require much
thought. But then the guy assigned to do one of the reports walked into my
office scratching his head, because he couldn't figure out where
Report X was supposed to get its data from. And we quickly realized that
Report X was, in fact, impossible to produce from the databases we'd
designed. It took our five-person team about two weeks to recover from the bite
of this particular rattlesnake.

Because paper prototypes have no code, they free you from the necessity
of building a working platform for your interface. So you can actually
start with the parts you have the most questions about, rather than those
that are most stable. The earlier in the project that you can explore your
areas of uncertainty, the less likely it is that they'll bite you later.

Sign 4. You're changing the way that the users perform a task.

It's surprisingly hard to change people's behavior, even when
there are clear benefits for them in doing something differently.
(Consider the failure of the efficient Dvorak keyboard to replace the
familiar but more cumbersome Qwerty layout.) Users are creatures of habit.
If they use your interface frequently, they might be so accustomed to it
that they can do some tasks without conscious thought. Similarly, if your
new design will change a standard work practice, there's a risk that
it will introduce confusion. I once tested a software application where
users came to a screeching halt because the interface automated a step
that they were accustomed to doing manually. Automating the step was a
fine thing to do, but neither the interface nor its help bothered to
explain that the step was now unnecessary. The problem was glaringly
obvious and also quite easy to fix, but because there had been no
usability testing done prior to release, the problem was causing headaches
for real users. Paper prototypes are quite effective at finding these
types of problems.

User acceptance can make or break an application. If you're
concerned about how the target audience will react to the new interface,
paper prototyping will let you spot any deal-breakers early, in time to do
something about them. Years ago I tested a paper prototype version of
Priceline.com. Their whole business model hinged on whether users would
accept Priceline's unique new way of selling airline tickets -- users
submit a credit card, along with the price they were willing to pay,
without knowing exactly what flight they might get. A handful of paper
prototype tests showed that people did indeed understand this concept and
were willing to use the site if they could get a good deal. However,
having to wait three days for an answer (which the original design called for)
was completely unacceptable. But because the paper prototype revealed this
problem before the initial launch, the development team could solve it
before any real users saw it.

Sign 5. The concepts or terminology are new to the users.

A crucial aspect of usability is whether users grok the concepts
embodied in the interface. This is a perennial challenge for sophisticated
applications -- because technology evolves faster than human language, we
must invent new terminology to describe the (sometimes overly arcane)
concepts. Almost every time I've usability-tested an interface, some
aspect of the terminology or concepts has proven to be confusing to
users. This is true in all interfaces, but especially so in high tech and
other specialized domains.

Sometimes, problems with terminology and concepts can be addressed
simply by changing a few words on the screen or by adding an example.
Other times, it goes deeper than that. The entities that users manipulate
in an interface are often reflected in the underlying data structures.
Change enough of the concepts, and you might end up having to change the
architecture.

So what does this have to do with paper prototyping? In essence, paper
prototyping helps you stabilize the functionality before you've
invested effort in implementation. If you have to wait until late in the
project before users can get a working version to play with, it may be too
late to make any substantial changes in response to their feedback. With a
paper prototype, you can flush these issues into the open much earlier and
take them into account while you're still in the design phase.

Sign 6. You're feeling uncreative.

Every prototyping method, whether paper- or computer-based, makes
certain things easy but doesn't help with others. When you're
prototyping with any type of software, you'll have a natural tendency
to gravitate toward the interface widgets that are supported by the tool.
Sometimes this is OK, but the drawback is that it can subtly discourage
you from innovating. Just as some guitarists compose at the piano to
prevent themselves from reaching for familiar chord progressions,
sketching an interface by hand could help you break out of a creative rut.
Switching to another medium engages different parts of your brain and
forces you to approach a problem differently. Some of my clients tell me
that just the process of creating the paper prototype is valuable to them,
even before the first user sees it.

Rest assured, you do not need to be an artist to create a paper
prototype. Forget about trying to make it look nice -- that comes later.
It's fine to use hand-drawn screens that have crooked lines and sloppy
text; the screens only need to be legible, not polished or artistic.
Users readily understand that the design is still "on the drawing board" and they won't beat you up over cosmetic issues. Instead, you can focus on whether the interface does the right things and works in the
way users expect.

How to Paper Prototype

Just as you don't begin a successful software project by blindly typing
code into the first class you think of, when you create a paper prototype it's
best to do some preparation before you start sketching the interface. (Though
if inspiration strikes, start scribbling on the back of that leftover wrapping
paper!) In this section, we look at how you start a paper prototype, how you
test it, and what you should do if your testing reveals that there are problems
with your initial design.

How do you start?

To create a paper prototype, start by making a list of the common or
important tasks that users will do with the interface. Sketch the set of
screens that are needed to do the tasks. (If the interface already exists,
you can start by printing screen shots and then redesigning them by hand
as needed.) Put interface elements such as drop-down lists on separate
pieces of paper so the Computer can place them on top of the main screen
if/when the user clicks the drop-down arrow.

Have a co-worker play the user and walk through the tasks, so you
can practice being the Computer, swapping the screens in response to what
the users do. Prepare all the screens that you think users are likely to
see, but you don't need to have all of the screens of the interface --
just those that are needed for the tasks.

How do you test a paper prototype?

Find a few real users and ask them to test your design. Rather than explaining
the design, give them a task and have them try it. (See Figure 2.) They don't
just look at the interface, but actually interact with it -- they "click"
buttons by touching them, "type" input by writing it on the paper, etc.
You play the role of "Computer." It's almost the opposite
of a demo, because in essence, you're asking the users to show you
how the interface works. Resist the temptation to explain the design -- in real
life, users won't have the benefit of your help. Instead, focus on understanding
which aspects of the design work well and which are confusing. Invite a few
other members of your team to observe, and ask everyone to take plenty of notes.

Usability Test
Figure 2. A usability test of a paper prototype. The user is on the left, and
the guy on the right is playing "Computer" by highlighting the option
the user has just clicked on. A member of the development team observes and
takes notes. The facilitator (not visible) is sitting to the right of the user.

It's also recommended to have a facilitator run the session. A
facilitator who is trained in usability testing will ensure that the users
don't feel like they're the ones being tested (it's really the
design that's being tested.) A good facilitator knows how to ask
questions in a non-leading way, which can be especially difficult for
those who are intimately familiar with the design.

What do you do when you find problems?

Sometimes you can fix simple problems on the spot, such as adding an
example next to a confusing edit field or changing a term. Other problems
require more thought. Immediately after the test, make a list of all of the
issues you observed and spend an hour or two making changes. Then hold
another test and repeat the process. After three or four sessions, you'll
have identified a number of issues and are likely to have solved many of
them.

Paper prototyping works very well as an iterative process, so don't
worry about making your initial design perfect. Instead, challenge
yourself to see how many improvements you can make. As my colleague Will
Schroeder likes to say, "The largest room in the world is the room for improvement." That perfectly captures the spirit of paper prototyping. Although no design is perfect, at some point it becomes good enough, and
paper prototyping will help you identify that point.

How long does this take?

Done correctly, creating and testing a paper prototype is not a very
time-consuming activity. Typically, it requires a few days to create the
initial prototype and prepare for testing, and then a couple of days to
conduct a handful of tests. A team's first paper prototype usually
takes the longest, until people get comfortable with the idea that it
really can be rough and unfinished. If even a few days sounds like a lot
of time, compare it to the time needed to rewrite substantial amounts of
code when you discover during beta testing what users really need.

Summary

Paper prototyping can help you avoid a lot of frustration by helping you solidify
the application you're designing, before you start implementing it. Once
considered a fringe technique, paper prototyping gained wide acceptance during
the 90s and is now used at many well-known companies. Why not make a New Year's
resolution to try it on your next project?

Got questions? Visit www.paperprototyping.com or email the author.

Carolyn Snyder is an independent consultant who specializes in usability testing and paper prototyping.
Related Topics >> GUI   |   Testing   |   Web Design   |