Six Signs That You Should Use Paper Prototyping Blog


    This time of year, there's plenty of leftover wrapping paper sitting around. Why not put it to g ood use? If you create interfaces, you may have heard of paper prototyping. It's a technique that lets you mock up, test, and refine a design -- totally on paper -- before you write a line of code. Figure 1 shows an example of a paper prototype screen, and the second half of this article has more details about the method. But first, we begin with some signs that paper prototyping might be right for your project.

    Figure 1. Here's what a paper prototype screen looks like, using the familiar Page Setup dialog box as an example. Although crude, even a hand-sketched interface is usually good enough to get meaningful feedback from users.

    When to Use Paper Prototyping

    Paper prototyping lets you conduct informal usability tests with real users early in the project, before the design is cast in concrete code. Here are six signs that your project could benefit from paper prototyping.

    Sign 1. There are many different ideas about the design.

    Maybe you sit in meetings arguing about how users will use the interface. Maybe you've got a radical idea that could result in a slick and elegant interface ... or land you in the usability hall of shame, if users can't figure out how to use it. Maybe there are different approaches to the design, and you aren't sure which is best.

    In practice, there will be times when any of the possible approaches will prove to be good enough for users, and you might as well flip a coin. Other times, they're all fundamentally flawed due, to some factor you're not aware of yet. In either case, it's a waste of time to debate the designs. Instead, you need to get user feedback.

    Paper prototyping makes it easy to sort the wheat from the chaff. Start with the design that's easiest to implement. Make a paper prototype of it and have a few users try it out. If the simplest design works (maybe with a few tweaks), then there's no reason to make it more complicated. On the other hand, if you learn that the simplest design isn't going to cut it, then prototype and test a more elaborate version.

    Building it with paper will tend to keep you focused on keeping the interface simple. Consider the implications of starting with the simplest design -- you're less likely to build things that users don't need. I've often wondered what percentage of development effort is spent on functionality that users don't really care about or aren't even aware of. It's kind of depressing to think about! But with a paper prototype, the opposite happens -- you can get reassurance early on that users will appreciate what you're building.

    Sign 2. You find yourself defending a particular design.

    Say you spend three weeks coding a working prototype. You show it to the marketing guy, and he immediately finds something he doesn't like. Or you show it to your project manager, and she can't figure out how to use it. Because you put in all of that work, you're likely to feel frustrated. It's understandable that you'd be tempted to defend your design instead of responding to the issues.

    Paper prototyping helps you avoid this no-win situation. Because it requires relatively little effort, compared to coding, a paper prototype makes it easier to let go of designs that aren't working. If you only spent a couple hours on a prototype and someone finds a problem, you can respond more objectively because you don't have a big investment in the design.

    Sign 3. There are parts of the design you're unsure about.

    There's always a temptation to start the design process with the parts you're more sure of, and defer the challenges and unanswered questions until later on, when you believe you'll have a better overall understanding of how the application or system will work. I know I fell into this trap many times when I was a programmer, especially when I was trying to get something up and running. (Of course, this may be an indication that I wasn't an especially good programmer!) But, as the saying goes, the rattlesnake you see is not the one that'll bite you. The earlier in your project that you can find the proverbial rattlesnakes, the better.

    Or you might assume that you understand something and later discover that you don't. I learned this lesson the hard way years ago, when I was a software project manager at a building controls company. We were developing a configuration application to be used by our company's field engineers. The application included a set of reports that showed information in the various databases. We had left the reports until late in the project, under the assumption that they wouldn't require much thought. But then the guy assigned to do one of the reports walked into my office scratching his head, because he couldn't figure out where Report X was supposed to get its data from. And we quickly realized that Report X was, in fact, impossible to produce from the databases we'd designed. It took our five-person team about two weeks to recover from the bite of this particular rattlesnake.

    Because paper prototypes have no code, they free you from the necessity of building a working platform for your interface. So you can actually start with the parts you have the most questions about, rather than those that are most stable. The earlier in the project that you can explore your areas of uncertainty, the less likely it is that they'll bite you later.

    Sign 4. You're changing the way that the users perform a task.

    It's surprisingly hard to change people's behavior, even when there are clear benefits for them in doing something differently. (Consider the failure of the efficient Dvorak keyboard to replace the familiar but more cumbersome Qwerty layout.) Users are creatures of habit. If they use your interface frequently, they might be so accustomed to it that they can do some tasks without conscious thought. Similarly, if your new design will change a standard work practice, there's a risk that it will introduce confusion. I once tested a software application where users came to a screeching halt because the interface automated a step that they were accustomed to doing manually. Automating the step was a fine thing to do, but neither the interface nor its help bothered to explain that the step was now unnecessary. The problem was glaringly obvious and also quite easy to fix, but because there had been no usability testing done prior to release, the problem was causing headaches for real users. Paper prototypes are quite effective at finding these types of problems.

    User acceptance can make or break an application. If you're concerned about how the target audience will react to the new interface, paper prototyping will let you spot any deal-breakers early, in time to do something about them. Years ago I tested a paper prototype version of Their whole business model hinged on whether users would accept Priceline's unique new way of selling airline tickets -- users submit a credit card, along with the price they were willing to pay, without knowing exactly what flight they might get. A handful of paper prototype tests showed that people did indeed understand this concept and were willing to use the site if they could get a good deal. However, having to wait three days for an answer (which the original design called for) was completely unacceptable. But because the paper prototype revealed this problem before the initial launch, the development team could solve it before any real users saw it.

    Sign 5. The concepts or terminology are new to the users.

    A crucial aspect of usability is whether users grok the concepts embodied in the interface. This is a perennial challenge for sophisticated applications -- because technology evolves faster than human language, we must invent new terminology to describe the (sometimes overly arcane) concepts. Almost every time I've usability-tested an interface, some aspect of the terminology or concepts has proven to be confusing to users. This is true in all interfaces, but especially so in high tech and other specialized domains.

    Sometimes, problems with terminology and concepts can be addressed simply by changing a few words on the screen or by adding an example. Other times, it goes deeper than that. The entities that users manipulate in an interface are often reflected in the underlying data structures. Change enough of the concepts, and you might end up having to change the architecture.

    So what does this have to do with paper prototyping? In essence, paper prototyping helps you stabilize the functionality before you've invested effort in implementation. If you have to wait until late in the project before users can get a working version to play with, it may be too late to make any substantial changes in response to their feedback. With a paper prototype, you can flush these issues into the open much earlier and take them into account while you're still in the design phase.

    Sign 6. You're feeling uncreative.

    Every prototyping method, whether paper- or computer-based, makes certain things easy but doesn't help with others. When you're prototyping with any type of software, you'll have a natural tendency to gravitate toward the interface widgets that are supported by the tool. Sometimes this is OK, but the drawback is that it can subtly discourage you from innovating. Just as some guitarists compose at the piano to prevent themselves from reaching for familiar chord progressions, sketching an interface by hand could help you break out of a creative rut. Switching to another medium engages different parts of your brain and forces you to approach a problem differently. Some of my clients tell me that just the process of creating the paper prototype is valuable to them, even before the first user sees it.

    Rest assured, you do not need to be an artist to create a paper prototype. Forget about trying to make it look nice -- that comes later. It's fine to use hand-drawn screens that have crooked lines and sloppy text; the screens only need to be legible, not polished or artistic. Users readily understand that the design is still "on the drawing board" and they won't beat you up over cosmetic issues. Instead, you can focus on whether the interface does the right things and works in the way users expect.

    How to Paper Prototype

    Just as you don't begin a successful software project by blindly typing code into the first class you think of, when you create a paper prototype it's best to do some preparation before you start sketching the interface. (Though if inspiration strikes, start scribbling on the back of that leftover wrapping paper!) In this section, we look at how you start a paper prototype, how you test it, and what you should do if your testing reveals that there are problems with your initial design.

    How do you start?

    To create a paper prototype, start by making a list of the common or important tasks that users will do with the interface. Sketch the set of screens that are needed to do the tasks. (If the interface already exists, you can start by printing screen shots and then redesigning them by hand as needed.) Put interface elements such as drop-down lists on separate pieces of paper so the Computer can place them on top of the main screen if/when the user clicks the drop-down arrow.

    Have a co-worker play the user and walk through the tasks, so you can practice being the Computer, swapping the screens in response to what the users do. Prepare all the screens that you think users are likely to see, but you don't need to have all of the screens of the interface -- just those that are needed for the tasks.

    How do you test a paper prototype?

    Find a few real users and ask them to test your design. Rather than explaining the design, give them a task and have them try it. (See Figure 2.) They don't just look at the interface, but actually interact with it -- they "click" buttons by touching them, "type" input by writing it on the paper, etc. You play the role of "Computer." It's almost the opposite of a demo, because in essence, you're asking the users to show you how the interface works. Resist the temptation to explain the design -- in real life, users won't have the benefit of your help. Instead, focus on understanding which aspects of the design work well and which are confusing. Invite a few other members of your team to observe, and ask everyone to take plenty of notes.

    Usability Test
    Figure 2. A usability test of a paper prototype. The user is on the left, and the guy on the right is playing "Computer" by highlighting the option the user has just clicked on. A member of the development team observes and takes notes. The facilitator (not visible) is sitting to the right of the user.

    It's also recommended to have a facilitator run the session. A facilitator who is trained in usability testing will ensure that the users don't feel like they're the ones being tested (it's really the design that's being tested.) A good facilitator knows how to ask questions in a non-leading way, which can be especially difficult for those who are intimately familiar with the design.

    What do you do when you find problems?

    Sometimes you can fix simple problems on the spot, such as adding an example next to a confusing edit field or changing a term. Other problems require more thought. Immediately after the test, make a list of all of the issues you observed and spend an hour or two making changes. Then hold another test and repeat the process. After three or four sessions, you'll have identified a number of issues and are likely to have solved many of them.

    Paper prototyping works very well as an iterative process, so don't worry about making your initial design perfect. Instead, challenge yourself to see how many improvements you can make. As my colleague Will Schroeder likes to say, "The largest room in the world is the room for improvement." That perfectly captures the spirit of paper prototyping. Although no design is perfect, at some point it becomes good enough, and paper prototyping will help you identify that point.

    How long does this take?

    Done correctly, creating and testing a paper prototype is not a very time-consuming activity. Typically, it requires a few days to create the initial prototype and prepare for testing, and then a couple of days to conduct a handful of tests. A team's first paper prototype usually takes the longest, until people get comfortable with the idea that it really can be rough and unfinished. If even a few days sounds like a lot of time, compare it to the time needed to rewrite substantial amounts of code when you discover during beta testing what users really need.


    Paper prototyping can help you avoid a lot of frustration by helping you solidify the application you're designing,before you start implementing it. Once considered a fringe technique, paper prototyping gained wide acceptance during the 90s and is now used at many well-known companies. Why not make a New Year's resolution to try it on your next project?

    Got questions? Visit www.paperprototyping.comor email the author.