Alertbox: Paper Prototyping

I pretty much agree with Jakob's April Alertbox Paper Prototyping: Getting User Data Before You Code: paper prototyping is not used as often as it should be.

I think the reasons center on fear factors -


  • People are afraid to talk directly with users, especially "naked" like this - it is much easier to have some technology between you and users
  • Some designers are afraid of the unpolished look - if the design is not 100% complete visually, they are afraid the results will be tainted.
  • Some are afraid of losing the online context, that you lose something without the user's hand on a mouse.

While losing context does happen with paper, it is generally OK to lose that for initial designs. With paper, people do see it as a more informal design and give better feedback overall.

And when you use the paper format to your advantage and let users really get creative, creating parts of the own designs on the fly, then you really get to see the benefits. You can do so many more things with paper designs - so much more than just measuring completion times and gathering opinions.

I have not read Carolyn's book yet - but I did scan it at CHI. I hope that one of her messages goes beyond Jakob's "earlier is better" article - for some design tasks, paper is just plain better than building anything with code.


This is a first in a new series for ia/ - "beat reporters" who watch an area and blog it. I volunteered to "beat Alertbox" so I will be adding my own comments to Jakob's articles.


Keith


PS I have very little association with Morgan Kaufmann - I have reviewed some proposals for them, and I eat their desserts at CHI every year, but that is all.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Clients too

The obstacles to paper prototyping don't only involve designers, they are erected by clients too. I had a job interview several years ago where, after doing paper protyping in my Human Factors class in grad school, I talked about the technique. The interviewers were software developers with advanced math and science degrees, and their attitude was, "You're going to build a prototype with what?" I didn't get that job.

This is probably a case where, if you need to explain it to someone, you're better off showing them how it works rather than only telling them.

Paper is good.

I'm on your team Keith. I totally agree with you on this.

Paper protoyping, despite the challenges (mostly in perception) is a great way to get all sorts of great information from users with out spending a lot of money or a lot of time but it has another great benefit. Especially when it comes to folks other than users - clients and stakeholders for example.

Doing paper prototyping, especially early, will allow you to gather data from people without setting any expectations or unwanted impressions. Lets face it - if you've done any user study with a fully fledged interactive prototype too early you know what I'm talking about. Especially when dealing with stakeholders and clients. If you use well thought out paper prototyping you can get the same feedback or data with less of the kickback or nitpicking on irrelevant bits and pieces.

D. Keith Robinson |
dkr@7nights.com |
Asterisk*

Examples?

Ok, maybe I am the type who does not use paper -- I am interested. Could someone point to some examples, maybe scanned paper prototypes? I doubt something that like is around, but it is worth a shot.

Thanks!

Examples of paper prototyping

In addition to the many examples in my book, I can offer a couple of places to look online.

The first is an article called, oddly enough, Paper Prototyping:
www-106.ibm.com/developerworks/library/us-paper/?dwzone=usability

The second is the brand-new site www.paperprototyping.com. The Examples page is still pretty sketchy; I hope to add more examples later (especially those contributed by others, hint hint).

I'm sure it's a good book, but...

The book is published by Morgan Kaufmann as part of their Series in Interactive Technologies, of which Jakob is an editor. Some of Jakob's books are also published by Morgan Kaufmann, and his quotes appear on many editorial reviews and back covers for Morgan Kaufmann books.

Doesn't it seem a bit inappropriate to review a book and call it “wonderful” without disclosing the fact that you are on the payroll of the publisher?

I don't mean to take anything away from paper prototyping (which I think is great), or the book itself (which, while I haven't read it, seems quite good), or even Jakob's review. I'd just settle for a little line at the bottom of the page that says:

Disclaimer: This book is published by Morgan Kaufmann, who also publishes some of my books, and I am on the editorial board of the series that this book is a part of. While I don't receive any direct kickback from Morgan Kaufmann for promoting this book, if you buy it, their revenues go up, and some of that money will probably eventually trickle back to me. Plus, even if they didn't ask me specifically to promote the book, I'm sure that they won't be upset that I gave them all this free publicity.

Okay, that's not so little... but even a one-sentence disclaimer at the bottom (like Fool.com has when writers mention stock that they own, either directly or in mutual funds) would leave me with a better feeling.

The Fear Factor

I agree with Keith that various "fear factors" may prevent designers and engineers from using paper prototypes, even when they believe in the basic premise that rough looking designs can be useful in eliciting feedback.

Consider that our culture (at least American culture) places importance on completeness and accuracy. When you were taught in childhood to cross your t's and clean your plate, you may feel nervous at the idea of showing someone something that's obviously incomplete - it might appear childish. And when you live in a country where you can be sued for negligence if you fail to finish shoveling your sidewalk and someone falls, it's easy to see why this fear remains alive and well even in grown-ups. But we rarely acknowledge this on a conscious level. So one thing I do in talking with development teams is to shine some light onto those imaginary monsters beneath the bed. Some people need reassurance that it's OK to experiment - I like to use Edison's line about discovering 10,000 ways to create a light bulb that *didn't* work.

I think it also has a lot to do with how engineer-types view the world, and what they're rewarded for. We (putting on my engineer hat, since I used to be a software engineer) tend to be perfectionists by nature. We value - and are rewarded for - creating things that are robust and error-free (think of the total quality, six-sigma concept). The thought of showing flawed designs to people, especially outside users, can provoke anxiety. One way that I counter this is to tell the development team that it's OK if not everything has been fully thought through, and I will not allow the users to criticize the design - if we uncover a gap in the interface's logic, we'll simply move on.

I'm interested in hearing other successful messages people have used to counter the "fear factor."

new education methods may help

One thing I find encouraging is that the education system is (albeit slowly) evolving to teach children early on that sharing incomplete work is "OK". When I was getting my graduate degrees, I taught a lot of freshman composition classes, luckily in two of the rhetoric-composition-PhD English departments in the country. What I learned there was how to teach kids to sit in small groups and go over each others' work, critique, share knowledge, have constructive conversations about improving and clarifying. These skills were just as important for them to learn as their solitary writing skills, perhaps moreso. I can't think of a thing of much importance these days that I simply write (or design) and 'publish'... it's always in concert with a group of collaborators, editors or clients. I find our designers have had to learn the same lessons... that it's not about huddling in your loft and emerging with a work of great genius. Even if we taught art history well, or the history of design, we'd be more clear about the fact that all the great designers and artists (and writers, for that matter) tended to be nurtured in a soup of highly collaborative and vocal peers and mentors.
So, anyway, nowadays many elementary, middle and high schools are using collaborative teaching methods, and hopefully kids will grow into engineers and designers who crave interaction with peers in order to do the best work. We'll see.

andrew hinton :: www.memekitchen.com