Looking Back on 16 Years of Paper Prototyping

by Jared M. Spool

Despite amazing advances in prototyping technology, paper prototyping is still one of our favorite tools for gaining quick insights on new designs. As we look back at how we’ve used this technique over the last 16 years, we can see that it has adapted well to the new demands from today’s design process.

The Basics of Paper Prototypes Haven’t Changed

In 16 years, building and evaluating paper prototypes hasn’t really changed very much. It’s still the simplest method we know for getting feedback about a design. All we need to do to learn about a design is to draw the design elements on paper and place them in front of our users, as if they are working on a real screen.

We learned a long time ago the secret to this technique: it’s not about ‘showing’ the interface, it’s about ‘using’ it. You want enough detail in the design for users to complete their tasks. Sometimes, this makes creating the prototype a little burdensome, but the quick ability to change the design outweighs the upfront effort requirements.

When you show a design to a user, you end up asking questions, such as “What do you think?” The users always reply with their opinions, but we’ve seen many times that what users say they like and how they interact with a design can differ dramatically.

Therefore, we focus more on whether they can ‘use’ the design than whether they ‘like’ it. To that end, we typically don’t spend any time on aesthetics when we build our prototype. Our paper mockups are typically ugly pages with text and not much else. We only represent the essential graphical cues necessary to operate the interface. It’s only in the next stage—testing the electronic version—that we start to look at the design’s aesthetics.

Detail in the design is still very important. Because we’re asking users to pretend it’s the real interface, we need the elements available and working. We’ve found that greeked-out or faked content forces the users to imagine perfectly working designs, whereas real-life representation will likely contain critical flaws. Since the reason we’re prototyping is to identify those flaws, we find it essential to draw everything out.

In the last few years, we’ve tried other tools, such as Microsoft’s Visio, to help build the interfaces for testing. However, we found it restrictive to have only one person updating the interface. When we’re just marking with pens on paper, everyone on the team can make changes simultaneously. This increases the amount of changes we quickly make between each test session, letting us learn more about radical design ideas in subsequent sessions.

Portable Printers Considered Helpful

Years ago, printers were slow and rarely located near the space where the team was creating their designs, forcing us to always draw out all the components by hand. These days, we often bring an inexpensive inkjet printer to make things easier. For less than $100, we now have a printer than can handle all the text. Typically, we find ourselves just creating the text for links and screen prompts in our word processor, still using scissors and glue to layout the page.

While design programs, such as Illustrator or Dreamweaver, have become much easier then when we first started using this technique, they are still too cumbersome to produce the rough designs we require for a quality paper prototype. Every time we’ve tried to use them, we find ourselves bogged down with lining things up neatly and other micro-design activities that take time and tell us nothing about the design’s effectiveness. The programs are great once the basic design elements are established, but for the initial round of paper tests, we find them to be overkill and distracting.

Our Tasks Have Become Fuzzier, Sometimes

The typical way we build a paper prototype is to create the tasks first, then build the interface components necessary to support those tasks. For example, if the tasks involve printing, we’ll create the menus and dialog boxes to support the print function. However, if there is no printing involved, we’ll leave those elements out of the prototype.

This implies we need a solid understanding of the tasks *before* we create the prototype. If we don’t know what users will do with the interface, it’s hard to know what we should build.

16 years ago, we were often testing application interfaces, such as network configuration utilities, where the design team understood the tasks well. Now that technology is pervasive, we find we often don’t understand what the users are doing with the design.

That said, paper prototypes are a very inexpensive way to explore tasks with the user. When we don’t have the budget to do field research or interviews, we make the test sessions more exploratory, turning the session into more of a “working interview.” We just need to make sure we allow time to change the interface radically between each session, as we learn the tasks that users really want aren’t the tasks that we originally thought.

Best for Testing Navigation

One lesson we’ve learned is that paper prototypes are ideal for testing the navigation elements of a design. Where they fall short is when we’re trying to learn something about content-rich designs, such as a knowledge repository. When we’re more interested in the content, we’ll skip over paper mockups and go straight to evaluating the electronic renditions of the design.

When we’re evaluating process-oriented interfaces, such as making a reservation or applying for a loan, we’ll often test two users in a single session, using a technique known as “co-discovery.” Co-discovery allows us to collect twice as much user data in the same time as regular testing. However, this doesn’t work well if the interface depends on the users making decisions from the content, such as deciding which product to purchase, as each user’s interest may vary greatly.

Group Prototyping is Key

We’ve found that the larger groups always get far more benefit from the process. Paper prototyping with large teams gets all the issues on the table, allows everybody to see the users’ reactions, and produces a cohesion we rarely find from other project activities.

We now recommend strongly that teams involve everyone in the paper prototype portion of the project. We hand out scissors and pens. We assign portions of the design to each team member. We have them practice the design on each other, before the users arrive. The intimate familiarity with the design that comes from these sessions is a great way to kick-start a project.

One of the biggest mistakes we see teams make is failing to schedule enough time between each test session to make revisions. Often they’ll only schedule 30 to 60 minutes, where we’ve found that 90 minutes or more is usually necessary. The downside of the shorter time is that they short-change the time they have to make substantial design changes. These radical changes give teams the most insight and help them produce innovative solutions to any nagging interface problems.

Electronic Versions Still Required

In woodworking, sandpaper comes in different grains. Course-grain sandpaper can change the shape of the wood dramatically, whereas fine-grain sandpaper gives the artisan the control to make the details sharper.

The same is true when designing. We think of paper prototyping as the course-grain sandpaper and electronic-version testing as the fine grain. Once we’ve used the paper prototypes to validate we know what each screen contains and how it will work, we then move over to the electronic version to fine tune the look and feel.

We’ve started using clickable PDFs as the next step after paper prototypes. Using Acrobat’s link and form capabilities, we can simulate practically every interactive element in the design.

Paper is still most effective for gross changes to the interfaces, as the construction of a clickable PDF is very clumsy and time consuming, especially if the design isn’t quite stable. It’s only when we’ve convinced ourselves the design is no longer changing drastically, do we move to the PDF file for testing.

Good for Another 16 Years?

It’s hard to say if we’ll still be using paper prototypes as much 16 years from now, but we’re sure it’s a technique that we’ll reach for frequently during many of our upcoming projects. The advancement of technology hasn’t replaced good old paper, when it comes to getting results quickly and effectively.

Published here on July 27, 2005.