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

1. Do the users understand terms chosen?
2. Are there key concepts they misunderstand?

Navigation/workflow

1. Does it match what users expect?
2. Do they have to keep flipping between screens?
3. Does the interface ask for inputs that users don't have, or don't want to enter?
4. What does the user 'press'? If these are not already links, they should be links in your new design.

Content

1. Does the interface provide the right information?
2. Does it have redundant or annoying information?

Page layout

1. Can users find information?
2. Are fields in the order that users expect?
3. Is the amount of information overwhelming, not enough, or about right?

Functionality

1. Is the interface missing functionality that users need?
2. 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

• paper prototyping examples
• Low-Fi Prototyping and Usability Testing
• Task Analysis and Interface Sketches
• Looking Back on 16 Years of Paper Prototyping
  

. CSS . XHTML . WCAG AAA .

created & designed by Vivienne Trulock for ilikecake