I just finished reading Carolyn Snyder's Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces, and I think I finally get it. Sure, I thought I understood paper prototyping, but it turns out, I was really missing some of the key aspects of the technique.
However, before I dive into what paper prototyping really is, we need to take a step back.
Every application is made up of two aspects: the UI that takes in and displays information, and the back end behavior. Some websites, like Google, have a really simple UI, and very sophisticated back ends. While other applications (and websites), like Photoshop, have both complex UIs and complex back end functionality.
Whenever you create a prototype, your goal is to develop something as close to the working model as possible. You'll probably take short cuts on either the back end logic (such as just forwarding the user to the next appropriate screen with data already filled in), or the front end UI (such as wrapping a complex process in a simple command line interface). But either way, something is going to give.
The goal with a paper prototype is to render the UI with (no surprise) paper. But it doesn't stop there. The back end process is modeled by, (surprise) a human. The human who's simulating the back end isn't simply doing random actions, but is performing against some scripted behavior. In the world of paper prototyping, this human is known as the Computer (versus computer in all lower case).
Consider this example of a paper prototype of Google:
Computer: shows a paper version of the Google home page
User: enter "Linux"
Computer: writes the word "Linux" in a text box
User: click submit
Computer: build a paper search results page with Linux results
...
The end result is that a paper prototype isn't merely something you look at for screen design, but is actually an extremely crude version of you're application. Without writing a single line of code, or designing any graphics for the UI, you have a version of your application.
I find this concept to be nothing short of remarkable. But, it actually gets better.
OK, you have this version of your application that you can now use to interact with, but what good is it? Well, there are a variety of things you can use it for. It's a good demonstration tool for other groups in your organization. It can also serve as a specification of sorts for your programmers. I find this specification idea to be a good one because it avoids you having to write a big thick spec, yet doesn't allow you to leave out any critical details. Synder's favorite use of a paper prototype is for usability testing.
And what is usability testing? Glad you asked. It's when you sit folks down in front of your application and observe them using it. There's some debate about what kind of things you can learn by doing this. But everyone agrees, you'll learn something. And probably something important.
Usability tests help learn what people are and aren't getting about your application. What buttons do they always miss? What processes do they always seem to want to do in reverse? And why the heck can't people figure out how to use cropping tool? It's the patterns of behavior, not specifics, that you are on the lookout for.
So, imagine it: you sit strangers down in front of your paper prototype and have them interact with it. You then learn things, and fix things about your application. Mind you, you've never written a line of code, yet you are already making important progress. How cool is that?
I actually like paper prototyping (now that I understand it) for a couple of reasons. First, it causes you to focus on what you really should be focusing on: the user experience of your application. Sure, you can make a screen prettier by sending it off to a graphics designer, but, you can't truly fix a broken process that way.
Secondly, I love the ratio of effort to feedback involved in a paper prototype. You've done almost no work extraneous work, yet you've gotten useful feedback on your system.
Snyder's book on this topic is no doubt the definitive source for information. Because of the close relationship between paper prototyping and usability testing, she manages to cover a significant amount on that topic as well. If you are even slightly interested in paper prototyping, pick up the book - it gives all the info you need to get started, and manages to inject just enough humor to keep it fun. You can also check out the book's companion website here.
For your next application, you might want to give paper prototyping a try. If nothing else, you'll have a great excuse to raid the office supply room. And, you may just discover that big flaw in your application before the programmers have exhausted themselves implementing it.
