Paper prototyping is a waste of time

Design on paper but always test with a screen

Paper prototypes are the macaroni artwork of software development. Let me explain:

Has a small child ever showed you artwork made from dried macaroni, glue, and construction paper? No matter what kind of mess you’re looking at, you always give the little tyke credit for trying, right?

“You’re so creative! Great effort!”

I’ve got bad news: If you’re using paper prototypes to test a new feature or product, you’re probably asking for the same kind of treatment. Starting on paper is great for your design process, but it’s a waste of time for research. Here’s why.

Paper prototypes generate false positives

First, let’s define a paper prototype. It’s a set of drawings, on paper, that are meant to show how your product works. So far, so good, because I love paper. At Google Ventures, I run a lot of design sprints with the companies in our portfolio (over 80 in the last 2 years) and we spend a whole day sketching detailed designs on paper — I’m convinced it’s a super-efficient way to think through your ideas before you lift a mouse.

Those paper sketches should never leave your war room. They’re for you, not for outsiders. Sure, they look cool. But if you try to use them for user research — if you show your drawings to target customers and expect to learn something useful—you’re going to waste everybody’s time.

Just like when you look at a kid’s macaroni art project, the target customers who see your paper prototype will probably be impressed by your creativity. They’ll want to play along. They’ll use their imagination and fill in the blanks.

You’re so creative! Great effort!

But when you need to learn about a business or product, the last thing you want is people using their imaginations and giving you creative feedback and encouragement. You want to get as close as you can to real world observation of real world customers. If the product doesn’t look real, the customer response won’t be real.

Get reactions, not feedback

When you show customers a paper prototype, you’re inviting feedback, not reactions. There’s an important distinction here: feedback comes from the brain, and reactions come from the gut. When you’re doing research to answer questions about your product, reactions are more useful — they’re closer to what the customer truly thinks.

Think about the last time you asked someone for feedback. What’s the first thing they do? They think. In the worst case, they’ll think up something to tell you just because you’re asking them.

But when you show someone a product for the first time, their reactions are palpable. You can see confusion, delight, surprise, understanding, excitement — whatever.

Remember: You’re the product designer (or CEO, or engineer, or product manager, etc). It’s your job to observe people’s reactions in the real world and decide what to do. It can be useful to ask friends or mentors for feedback, but when you’re talking to customers, aim for reactions.

Paper prototypes don’t save time

The leading argument for paper prototypes is that they’re so fast to make. All you have to do is draw! How hard is that?

Well heck. Drawing isn’t that easy. If it has to look realistic enough to show people, if it has to have the right text and everything — that’s gotta be a pretty good drawing. I’d guess that’s going to take a few hours.

But you know what? Even if you can create a full-fledged interactive paper prototype in 39 seconds you’re still wasting your time if you test it on users.

Testing on users takes time. Time to find people who look like your target customer. Time to schedule them. Time to prepare your interview so you’ll learn as much as possible (and avoid asking leading questions). And time, of course, to do the actual interviews. Not to mention the time you’ll spend afterward, digesting what you’ve learned.

After all that time spent, if you tested with a paper prototype, you can’t trust what people tell you. For 100% of the research time, you get maybe 5% of the confidence.

High fidelity is a little harder and a whole lot better

For optimal feedback, mock up something that looks real enough to go head-to-head with your competitors’ real products. You’d be surprised by how easy that is. A high-fidelity prototype can be built in as little as 4–8 hours using tools like Keynote and Keynotopia. If you’re interested, here’s how we create rapid prototypes in one day at GV.

Paper is great for starting design work, but it’s the wrong tool for testing. So put down the macaroni and get real.

If you liked this post, check out my book Sprint, about the Google Ventures design sprint method. It’s a book about surprising ideas: that the biggest challenges require less time, not more; that individuals produce better solutions than teams; and that you can test anything in one week by building a realistic façade.

Sprint comes out on March 8 in hardcover, e-book, and audiobook. Pre-order it here.