Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Five Paper Prototyping Tips

by Matthew Klee
on March 1, 2000

We’d like to respond to some of the questions we’ve heard recently at our courses on prototyping, and provide tips on how to make
this technique work well for you.

Prototyping is a quick way to incorporate direct feedback from real users
into a design. Paper-based prototyping bypasses the time and effort required
to create a working, coded user interface. Instead, it relies on very simple
tools like paper, scissors, and stickies. Even in applications where new technologies
are deployed, paper provides maximum speed and flexibility.

Equally important is that everyone on the development team can stay closely
involved and productive in the process of creating a paper-based design. Because
everyone on the team is a witness to direct user feedback, designers, developers,
and writers can confidently implement a solid design that really works for
its intended audience.

1. I’m proficient with HTML. I can create a working prototype fairly
quickly. Why would I want to use paper prototyping?

Certainly, you can use HTML (or Visual Basic, SuperCard, or other rapid development
tools) to create mockups, but you may want to consider whether you have enough
people who are proficient with the tool you’ve selected. Another issue
to consider is how well your design team can stay involved in the prototyping
process.

The reality is that it’s very difficult to keep the entire team involved
in the process if each person is creating her own HTML pages at her desk. We’ve
seen that most usability problems stem from someone with key information not
being involved in the design process. With paper, everyone can gather around
one table with their eyes on the same design and each team member can contribute
as the design unfolds.

Another advantage of using paper over HTML is that changes can be made on
the fly during a test. If a design doesn’t work the first time out, designers
can scrap it and quickly try another with the same user. For example, if a
user is stuck and needs additional information, a “Hints” button
can be added on the fly.

Finally, users feel more comfortable being critical of a paper prototype because
it doesn’t have a polished look. When something doesn’t work well
in a crisp looking prototype, users are more likely to blame themselves or
their lack of experience. The goal in prototyping is to measure the function
and flow of the interface, not the look. HTML and other tools will create a
polished look but won’t change how quickly and easily a user can accomplish
a task.

After you’ve done several iterations of testing and design on paper,
putting together a web site will not take long. You will have saved time
by making the big conceptual changes early on in the design process.

2. How can I use paper mockups to test new technology? Trying to mimic Macromedia
Flash using paper mockups sounds like a nightmare—and how would we create
rollovers?

The goal in testing a prototype is to create a usable site. The inability
to prototype a fancy effect on paper may be a warning that the effect is not
usable. Our data with rollovers indicates that users can’t distinguish
a rollover from a static graphic. (A rollover is a graphic that changes, reveals
text, or otherwise affects the screen when the mouse pointer is placed on it.)
Users often choose a link to click on before seeing the associated content
in a rollover.

Sometimes designers will use a new technology not necessarily to create a
more usable site but because it looks cool. As long as the coolness of the
site doesn’t interfere with its usability, go for it. The goal of the
paper mockup is not to test how cool looking a site is—it’s to assess
if users can get stuff done.

Paper mockups don’t need to incorporate all the frills of technology—they
only need to capture the site’s functionality and convey the right information.
For example, rollovers only need appear when a user goes looking for them.
When users are clearly looking for a rollover, we provide any that exist by
using a paper sticky.

3. Our product has been up and running for a while. Why go back and create
mockups to test an existing product? When should we start from scratch with
paper?

With prototyping, the key is to create an interface quickly. To test out a
completely new design creating a paper prototype is the fastest way to go.
If we want to test out an existing product with no changes, then we just test
the product.

When changing only parts of an existing interface, we start by printing out
existing screen shots. We then make any small changes on those screens using
sticky paper, whiteout and other handy prototyping supplies. If there are significant
changes for one screen we sketch the entire screen on paper. It’s fine
to mix screen shots with hand-drawn interfaces.

However, when making a small change we do so with care. If that small change
is handwritten on an otherwise clean screen shot it may artificially draw users
to that part of the screen. For example, do users see an added button because
of the button itself—what it says, where it is located—or because
it looks distinct and separate from the rest of the design? One idea we’ve
played with is to create dummy changes on other parts of the screen. That way
a single design change doesn’t stand out so much.

4. How do you create a prototype that relies on a database? Do you create
fake accounts? It seems like a ton of paperwork.

When users are doing tasks with data, you want the data to be as real as possible,
but it’s often impractical to have lots of data available. Using data
that isn’t real can work, but it makes the test less realistic for users
and can make their tasks unrealistically difficult. All else being equal, using
real data will make test results more reliable.

In cases where users must look up data that is not provided in a prototype,
we create tasks in such a way that we can predict the data. For example, when
we tested inventory tracking software, we designed tasks that had the user
track specific items in inventory and we had the data ready for each item involved
in the tasks.

When a user enters real data into a field and the data needs to appear somewhere
else later, we rely on sticky paper; this saves lots of time. Each field has
a piece of the sticky paper, and when the user enters data we can easily transpose
that data to another sheet. For example, in testing online ordering for a web
site, address information entered on one page is easily moved to the order
confirmation page by moving the sticky paper on which the data is written.

5. It’s not easy to make links look like links in a prototype. How do
you help users identify a link?

On Internet sites we see users try to click elements that aren’t links
and miss links they’re looking for because they don’t look like links.
When we see this in paper prototyping, we create the “incredibly intelligent
mouse”
—a fancy way to say we let the user decide what’s
a link simply by following their behavior.

When users click something that isn’t a link, the incredibly intelligent
mouse works and makes the non-link a link, bringing up the page the computer
thinks the user wants. If we see users click something time and again that
isn’t a link, it’s clear what’s needed—make it a link.

Sometimes a design will include icons and other detailed graphical links that
can’t be easily duplicated with paper. In this case, we write that graphical
link out in text. Do what’s quickest. If it’s important to have a
picture with the link (or as the link), we may provide a basic sketch, or copy
the graphic from some existing product and print it out on paper. •