Paper Prototyping
What is Paper Prototyping?
Paper prototyping is a method of usability testing that is useful for Web
sites, Web applications, and conventional software. Here's how it works:
- You first decide on the tasks that you'd like the user to accomplish.
- Next, you make screen shots and/or hand-sketched drafts of the windows,
menus, dialog boxes, pages, popup messages, etc. that are needed to perform
those tasks.
- Then you conduct a usability test by having one or two developers play
the role of "computer," manipulating the pieces of paper to
simulate how the interface would behave.
- Users are given realistic tasks to perform by interacting directly with
the prototype -- they "click" by touching the prototype buttons
or links and "type" by writing their data in the prototype's
edit fields. (Using transparency or removable tape prevents the prototype
from being written on directly.)
- A facilitator (usually someone trained in usability) conducts the session
while other members of the development team observe and take notes.
- If the session is conducted by a single person, care should be taken to write up notes as soon as possible following the evaluaton.
- The "computer" does not explain how the interface is supposed
to work, but merely simulates what the interface would do. In this manner,
you can identify which parts of the interface are self-explanatory and
which parts are confusing. Because the prototype is all on paper, you
can modify it very easily to fix the problems you find.
When conducting a paper prototype, you can do the following
- Write tabs on a separate piece of paper so it can be moved to the
front if the user selects it.
- Drop-down list should also be written on a separate piece of
paper which is shown if the user touches the drop-down arrow, or dropdown link.
- Radio buttons can be simulated using smaller pieces of paper which can be moved.
- User inputted data can
be written onto a transparency so they can easily be removed with a damp paper towel.
- User inputted data can also be written onto sticky notes which can easily be moved, removed and replaced.
How good should the prototype be?
You can use screen shots of an existing design if you happen to have them,
but it's also fine to hand-sketch them, especially when you're in the early
stages of design. Sometimes hand-drawn elements are actually more readable
than screen shots that use a dark background color.
You can also mix and match screen shots and hand-drawn components. The
prototype only needs to be good enough for you to get answers to the questions
you're most concerned about. Thus, most paper prototypes don't need:
- Straight lines or typed text. If the user can't read something, it's
OK to tell them what it says. (But if the user doesn't understand a term,
don't explain it -- change it.)
- Images or icons. Use words instead. For example, for the company logo,
you can just draw a box around the words "company logo." If
images are part of the content (a product catalog, for example), you can
paste them into your prototype using restickable glue, which allows you
to rearrange the page later.
- Color. Color can't save an inherently flawed design. You can do initial testing with grayscale printouts of screen shots, or sketches
using any dark-colored marker. Color can be added later.
- Consistent sizing of components. Unless you've got a small or densely-packed
display, don't worry about adhering exactly to a grid. It's OK if components
are of varying sizes. For example, perhaps your menu bar and icons came
from a screen shot and are relatively small compared to the hand-drawn
parts of the screen. You can clarify by saying things like, "This
is all one window," if the user seems confused.
It's fine if the prototype looks a bit messy. Very often, the first usability
test will show you problems you'd never anticipated, and then you'll want
to make changes. Don't spend time making the prototype look neat before
you test it -- if it's legible, it's good enough.
Paper prototyping is especially useful for gathering data about the following
kinds of problems:
- Concepts and terminology
- Navigation/workflow.
- Content.
- Page layout
- Functionality.
Why Use it?
Sometimes paper prototyping will uncover planned functionality that doesn't
need to be implemented.
Three researchers at Verizon (formerly GTE Labs) compared the type and
number of problems found with a low-fidelity (i.e., paper) prototype as
compared to a working prototype. They found that there was a significant
degree of overlap between the problems found using the two different methods.
Although the working prototypes did uncover a few more problems, they also
took significantly longer to develop than the low-fidelity ones -- weeks
instead of days. These results indicate that there are diminishing returns
from taking the additional time to develop a polished prototype.
Some development teams use paper prototypes in the early stages and then
do a couple of additional usability tests later with the real interface
to look for any additional surprises.
Task List
Below are questions which should be answered through using Task Analysis and Paper Prototyping.
Concepts and terminology
- Do the users understand terms chosen?
- Are there key concepts they misunderstand?
Navigation/workflow
- Does it match what users expect?
- Do they have to keep flipping between screens?
- Does the interface ask for inputs that users don't have, or don't want
to enter?
- What does the user 'press'? If these are not already links, they should be links in your new design.
Content
- Does the interface provide the right information?
- Does it have redundant or annoying information?
Page layout
- Can users find information?
- Are fields in the order that users expect?
- Is the amount of information overwhelming, not enough, or about right?
Functionality
- Is the interface missing functionality that users need?
- Is there too much superfluous functionality that users don't care about?
Examples
See a photo of a paper prototype.
Read how a team spent 6 days creating & testing a Paper Prototypes.
Read some examples of the successful use of Paper Prototyping in the Case Studies.
Limitations Of method
Paper prototyping isn't ideal if your biggest questions pertain to:
- Technical feasibility. Paper prototypes don't demonstrate technical
capability. It's possible to create a paper prototype that can't actually
be implemented. To avoid this, I recommend that there always be at least
one person involved who understands the technical constraints.
- Download time or other response time. Because a person simulates the
behavior of the computer, the "response time" is artificial.
- Scrolling. I've seen some interesting and subtle problems with Web page
designs that discourage the user from scrolling either down the page or
back up to the top. I wouldn't have found these problems with a paper
prototype.
- Colors and fonts. If you really need to see how something looks on a
computer screen, paper prototyping can't show you that. It's a good idea
to involve the graphic designer in the paper prototype tests because he
may find issues that influence the visual aspects of the final design.
Exercise
Create a paper prototype using screen shots provided in class
Reading