Paper Prototypes: Still Our Favorite

by Tara Scanlon

We’ve been creating paper prototypes and teaching others to use them for the past eight years. In that time, we’ve learned a lot about what paper prototyping is all about and we’re still pleased by what an effective and easy-to-use tool it is.

Still the Simplest

Even after trying other prototyping techniques, we’re still convinced that paper works best. We and our clients use it for many projects these days, just as we did when we first started eight years ago.

It’s certainly the easiest method to use. With nothing more than common office supplies, we sketch and hand-print on a piece of paper or index card each interface element that changes on the screen: dialog boxes, menus, error messages. Once we’ve built the entire design, we ask users to complete tasks by interacting with the paper interface, just as they would if it were implemented on the screen. If the first prototype interface has flaws—and they all do—it’s a snap just to scribble out a changed element and see if that fixes the problem. (And we save the flawed version and an explanation, just in case someone is tempted to try it again.)

Although paper prototyping often seems counterintuitive at first, we’re always pleased at how quickly developers and users understand how well it works once they start using it. Some sessions become quite animated.

Paper prototyping still has advantages over electronic prototyping technologies, which still haven’t quite caught up with paper even after all these years, and we don’t use such things as Visual Basic. These days we may start with captured screen shots more often than we used to, but this is because it’s become so much easier to produce them. Once we start modifying the screen shots, it’s easier to do that with paper, glue, and photocopies than to recreate the screen with a drawing program.

One of the best things about paper prototyping is that it works well both for software and web-site designs. Working on paper for a web site takes a little imagination (for example, we’ve discovered that fan-folding a piece of paper can simulate a long, scrollable page), but the point-and-click metaphor works well for both designers and users.

A Team-Building Tool

Paper prototyping is not only a good tool for building designs; it’s also excellent for building teams.

A development vice president once told me he was astonished at how quickly we got his developers to “play nicely” with each other once they started building and testing paper prototypes. He said he’d been trying unsuccessfully for months to get them to work together. But in only a week, all the team members were focused on the same goal and had made tremendous progress, thanks to paper prototyping.

The act of creating a paper prototype brings a disparate team together in several ways:

Many of our projects start with a meeting where the team is assembled, often for the first time. The act of building the prototype quickly and effectively brings team members up to speed. As they create the interface, they’re immersed in the design of the application.
The process forces developers to understand that the design team is more than programmers, managers, and documentation folks. Because it’s so simple to use, paper prototyping encourages everyone to pitch in—and on an equal footing. It’s rewarding to see how quickly everyone recognizes the value of all those different perspectives.
While watching users work with the prototype, the team sees the design through the users’ eyes. As usability problems emerge, the team discovers the users’ true priorities—and how differently users view the interface. It’s as difficult for developers to ignore something that causes problems for every user as it is to argue strongly to change something they all used successfully.

A Design and Testing Tool

Things were different when we first started using paper prototypes. Developers used electronic prototypes for demonstrations, but what they produced wasn’t flexible or rigorous enough to let real users do real work, and that prevented us from collecting any feedback on their use. We had to wait until the real product was done before we conducted usability tests, and that was often too late for the team to correct any serious problems they uncovered.

The advent of paper prototypes made it possible for us to start usability testing earlier in the development process, and we’re discovering—and fixing—serious usability problems within the first few weeks of a project. After paper prototyping, we’ve even seen some projects change direction completely.

We’ve learned that a paper prototype is a design tool, not only a testing tool. By putting designs in front of users and watching them work, teams can identify key requirements that users may not even have mentioned. They also see that different users respond differently to the same interface, giving them a better understanding of who the users are and what they need to accomplish.

A Communicating Tool

When we first started prototyping with paper, we didn’t realize it would be so different from other prototyping techniques we’d used. We thought we would produce the prototype from a specification, try it with a few users, make and document changes to the specs, and then put the prototype aside as we started development.

But we’ve learned that the prototype itself is more than a disposable instrument to gather design changes. Teams we work with use the prototypes in ways we never expected:

Defining Requirements: Teams increasingly use paper prototypes to help generate requirements. Every time they test a design, they uncover new requirements. By having real users do real work with the prototype, they end up with more accurate requirements than any other process would give them.
Building Living Specifications: Instead of tossing out the prototype after testing, many teams bring it to design meetings and use it as a working model to demonstrate the interface. Instead of reading a spec, people can “use” the prototype to understand how it works.

Nothing is Perfect

It can be labor-intensive to create a paper prototype, especially the first one. Paper prototyping is sometimes easier with a larger team, because the work can be shared. With only one or two developers, it’s necessary to block out more time to create the initial prototype. Teams we’ve worked with take an average of about 12 hours to create their initial paper prototype. Subsequent prototyping efforts often take less time because people discover shortcuts (such as photocopying frequently-used screens) and many of the pieces can be re-used.

We’ve also learned that HTML is almost as fast as paper prototypes, especially if the team is small and proficient with the tools. We occasionally use it as an alternative. However, if the project has lots of graphics or uses more than plain-vanilla HTML, it probably makes sense to use paper. (Using a word processor to create the page contents can be helpful.)

Facilitates Regular Testing

Some development teams quickly recognize the short-term benefits of paper prototyping, primarily team building. But they may miss another advantage: paper prototyping is so versatile and efficient that it facilitates regular usability testing, an incredibly valuable long-term benefit.

Organizations that build and test only a single prototype don’t get the value of trying different alternatives and learning from a large number of users. In our experience, the groups that get the most out of the technique have turned it into a major design tool that lets them do testing often.

After eight years, paper prototyping is still our favorite technique for designing and testing applications and web sites, and we plan to keep using it in our client work and our classes until something better comes along.

Published here on May 1, 1998.