Originally published: May 01, 1998
Weve been creating paper prototypes and teaching others to use them for the past eight years. In that time, weve learned a lot about what paper prototyping is all about and were still pleased by what an effective and easy-to-use tool it is.
Even after trying other prototyping techniques, were 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.
Its 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 weve 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 its 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, were 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 havent quite caught up with paper even after all these years, and we dont 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 its become so much easier to produce them. Once we start modifying the screen shots, its 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, weve 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.
Paper prototyping is not only a good tool for building designs; its 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 hed 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:
Things were different when we first started using paper prototypes. Developers used electronic prototypes for demonstrations, but what they produced wasnt 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 were discovering and fixing serious usability problems within the first few weeks of a project. After paper prototyping, weve even seen some projects change direction completely.
Weve 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.
When we first started prototyping with paper, we didnt realize it would be so different from other prototyping techniques wed 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 weve 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:
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, its necessary to block out more time to create the initial prototype. Teams weve 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.
Weve 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.)
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 dont 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.
Read related articles: