Five Paper Prototyping Tips

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.