Discuss 7 myths about paper prototyping

I think that paper prototyping is just a fad. Yes, one can use paper prototypes. But just because we can make paper prototypes does not mean we should. I prefer specialized software tools.

Sketching is OK. It is good for thinking, discussing, and generating ideas. But sketching is not the same as prototyping.

Transforming the sketches into prototypes on paper is a waste; both of paper an of time. I design and evaluate interfaces. I do a lot of sketching. I have tried even paper prototypes. My experience shows that an electronic tool is faster, simpler, and cheaper to use than paper. Of course, you need some getting used to the tool before that. Using a specialized tool is preferable but Word and Excel can do a good job too.

I think that something that can take me to 'paper' prototyping is a good tool that will allow me to sketch on the screen.

Re: Wireframes - personally I don't like to make the distinction you have in the article.

For me a wireframe can be one of many things, from a rough sketch on the back of an envelope to a very detailed and interactive prototype built with something like Axure, and anything in between. In my experience It depends on the nature of each individual project and its stakeholders as to what type of wireframe best suits the project needs, and throughout the course of a project that may well change. A few initial sketches might do a communication job at the start of a project, more detailed and structured wireframes might be needed later on.

I think of "Wireframes" as a broad category which contains many different flavours. It's up to us as designers / architects to choose the right flavour of wireframe at the right time to keep the project on track.

Surely the 'fad' at the moment is this idea that one solution can be right for all prototyping scenario's.

HI, I really like this. The myths are spot on. In particular I like the video about how interactive a prototype can be. My one worry in watching it was that it goes to a pretty low level of detail, testing drop downs and all. For the most part my experience doing paper prototypes has shown for testing the overall concepts, structure, and flow you don't need to go to that level of detail. Unless you are really testing the correct content of a dropdown it's not worth the effort of assembling.

So be sure you know what you are testing and it will be helpful. I actually wrote an article for UXmatters on the difference between sketches, prototypes and wireframes where I talk in more detail about the right tool for the right time in the process which can be found here www.uxmatters.com

This article sounds like a last desperate gasp fighting for Paper Prototyping's survival. Let's face reality--it's being overtaken, as the digital toolkits become easier to learn (whether web-based, or mobile device, or even Flash/Dreamweaver/Fireworks or Expression Blend) and upcoming generations of designers currently in school are more adept at making their own apps and interfaces digitally to the point that the cost (time investment for making, and learning curve effort) goes down. Not an emotional rant, just stating how it is. PP's value is only at early stage "internal" concept assessment and even then, must be validated with design further exploration.

Two things you should look at:

a) How PP fits within the broader spectrum of prototyping tools and how it stacks up in terms of design decisions and utility, framed by this interactive diagram: make.goinvo.com

b) A blog post I wrote up commenting on how TechCrunch harshly criticized a PP demo of an iPhone app, where I point out the core issue with PP, that it's not the real thing and totally unsuitable for random people to give useful feedback.
www.ghostinthepixel.com

FWIW, I'm an interaction designer with 10 yrs experience at companies like Adobe, Oracle, Cisco, and frogdesign and educated at Carnegie Mellon and Univ of Michigan. I've designed UI's for Netflix, LinkedIn, and iPhone start-ups as well, from sketch to hi-fidelity web prototypes. "Paper prototyping" as I've done it was only for early concept assessment internally among the team, not as a usability validation tool with outsiders. Because it has no validity. Time for task completion for moving pieces of paper around is nothing like task completion of a hi-fidelity dynamically coded up version running in the browser (or on the device) with real icons and button styles. Plus there are other variables to consider that shapes a person's judgment and utility of the design, such as visual appearance, smoothness of animations/transitions, performance of interactive behaviors, speed of feedback, visual and auditory affordances, and of course the typographic legibility of the content.

Another way of putting it, is the fidelity of your prototype is proportional to the fidelity of the feedback you receive. If it's lo-fi and crude, you'll get raw, general, lo-fi feedback. If it's hi-fi and polished, you'll get specific detailed input.

I do have to take issue with your dismissal of Myth 5, as I've personally seen interactive prototyping be MUCH more beneficial for *modern* design than paper prototyping (unless we're talking exploratory design in which paper has many advantages).

Those studies in the "raft of research" cited? From what I could tell, only two of them definitely focused on websites, and they were from 2002 & 2003. This was when the Web was still largely page-based. You click and you get either a page or a pop-up. Any other interactions required pulling developers' teeth. The other studies were from the late 90s, and if they *did* focus on the Web, my previous comments apply even moreso. Even if those studies focused on desktop apps, those days were the sunset of Windows 3.1 and the dawn of Win 95 and Mac OS X. Desktop applications on these systems were still pretty primitive and were easily rendered on paper.

Since 2005-2006, however the Web has become MUCH more interactive, and many of these interactions are too complex to demonstrate effectively on paper let alone gather accurate user feedback from them. On top of that, usability testing has made a significant shift out of the lab and into WebEx. Paper prototyping is rather difficult remotely (and no, clickable PDFs don't count as "paper," just irritating-to-build interactive prototypes : ). Besides, we now enjoy an overabundance of rapid interactive prototyping tools that we have no excuse not to be using.

Paper prototyping absolutely definitely has its place very very early on in the design process. But rapid interactive prototyping is the modern interaction designer's most important and powerful tool.

Good post. I also agree with a lot of the the comments above, particularly Chris Hart's. The more we can get to "technique x is a really great way to do these things" and away from a general "technique x is better than technique y"--an assertion that is never going to be universally true--the more constructive the conversation gets. David's post definitely contains some of this goodness, but when the article is prefaced by a statement like "paper prototyping is probably the best tool we have to design great user experiences," it frames those observations in a dueling-tools context.

Prototypes answer questions. What questions are you trying to answer? Figure that out, *then* choose an approach.

We're also using Axure's prototype wireframe software. I think it is more meaningfully for working in time and with less resources.

Ok, paperframes just looking very nice and you could work with them a little bit. But in the end the software solution is in my eyes the better way.

I was with you at the beginning of the article - I always sketch our interfaces on paper - and they don't look pretty but they get the point across and they provoke discussion and you make good plans.

But then you lost me when you said what you did about wireframing, and I agree with the comment above that I don't like your definition of wireframing. I'd say that what you call paper prototyping is wireframing - just on paper rather than a computer.

We certainly don't wireframe near the end of the design process; that would be completely pointless. We wireframe before any design is done and just literally show functionality, saying that boxes can change sides or colour etc. as the design dictates. It's the flow and features we're talking about, as are you. And I'm not limited if I don't have a "carousel" box to tick - well no more than you are on your piece of paper anyway - I just draw a rectangle and put a note as to what's going to be there.

Also, I'm afraid I felt you really were clutching at straws when you said how easy it is to scan your paper prototypes and put them into power point... eugh, like I say, I love pencil sketches and rely on them to begin with... but then it goes into Axure, I can move my templates around, I can add neat little foot notes (and never run out of room on the sheet) and then "click" "save" "email".

Liked the article overall though :) And you really can't beat some note book sketches to get things clear in your head at the start of a project.

lx