Paper Prototyping Session

Today I had the opportunity to spend most of the day working on a Paper Prototype for an application I'm helping to design. Like most usability techniques, Paper Prototyping is one of those activities that people seem to talk about more than do. So, I was excited to actually practice what I've been preaching. Here's some general lessons learned from the day:

• Paper Prototyping made me feel like I was in 5th grade art class again. We had note cards, tape, scissors, etc. strewn about. We even picked up scented markers, to add to the experience. This state of mind is both a good thing in that it helps induce creativity, and is potentially a bad thing, because it makes me wonder if other's will take our project seriously.
• Paper Prototyping isn't about UI design or layout. Sure, you need to organize the pieces of the application in an clean fashion, but I can see how design decisions such as tabs vs. buttons vs. drop down boxes, are going to need to be decided by a designer at a later date. Again, this is both bad and good. It's bad because the prototype looks crude, and which doesn't help with our credibility. But it's good because we can focus on what's important: the user experience. If the experience is good with basic controls, it should be fantastic with well designed components.
• Having a Paper Prototype to actually execute scenarios against made a huge difference in developing the user experience. It changed the tone of the conversation form one that was about anecdote and example, to one that was based on the needs of the specific application. Consider if our app had a spell checking requirement (which it doesn't really). Previously, if we talked about the spell checking feature we might say: "should we make it like Firefox's spell checking? How about gmail's? I kinda like Blogger's. What about doing it like old school MS-Word?" With a Paper Prototype our conversation went more like "at this point, the user is about hit send, wouldn't it be great if all the words were highlighted that were spelled wrong, and the send button grayed out?"
• Making a detailed prototype takes serious time. It's easy to throw the basic components in place (a search box here, a text area there) but it's another thing to develop the complete UI with every message and feature a user is going to see. I still think it's worth doing, it just takes more time than I had expected.
• Having Personas defined ahead of time was helpful.
• The Paper Prototype promoted an environment where different approaches could be easily suggested and evaluated. Again, the tone changed from one of: "Which do you think is better, A. or B.?" To, "let's implement A and B. Can we tell which one appears to be more appropriate?"
• The team makes a huge difference. Our team was fantastic. They were excited to try the Paper Prototyping approach, everybody participated with making components as needed, and most importantly, people suggested ideas and were willing to accept ones that weren't their own.

At the end of the day, I'd say there were some pretty remarkable advantages to making a Paper Prototype. I still wonder if others will take us seriously - but we'll know the answer to that soon enough.