I’ve been reading Carolyn Snyder’s “Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces“. It is a very thorough newcomer’s introduction to this simple yet effective user research technique.

Over the last year or so I’ve become quite interested in prototyping techniques in general - from flash and PowerPoint to even spaces like Second Life as prototyping environments - but I think paper prototyping stands out as something quite special.

Quoting from Snyder’s first chapter (p4), paper prototyping is-

“a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person “playing computer,” who doesn’t explain how the interface is intended to work.”

Paper prototyping is particularly interesting because it allows designers to try out their ideas for an interface long before anything needs to be put together by programmers or engineers. The hand-drawn paper-y nature of the prototype also encourages users to give in depth feedback, and to express ideas and reactions to the interface that aren’t tied into its look and feel. It allows the whole process to really focus on user work-flow and interaction.

Because the research participant is interacting with a ‘human computer’ the process encourages conversation between the user and the design team, who ideally sit in on the process, in a relaxed and friendly atmosphere.

Again, because the interface can be mocked up in 15minutes with a pen and paper, the development team is much more open at this stage to making dramatic changes to their design, listening enthusiastically, and acting on what the user says.

I think paper prototyping could be a really neat tool for libraries!

When we’re designing interfaces that our patrons will use (for example, our library web presence) we’re usually on a much slimmer budget than other organizations. We can’t really afford the money (or the time) involved in redoing a live website prototype over and over again. Most often our situation is enhanced by the fact that we have to hire outside help to actually build the bulk of these tools for us.

Paper prototyping could be a tool that we can use to cheaply test and refine our ideas before we start the building process:

• We could test our ideas in front of key representatives from our patron base,
• investigate the kinds of needs our users have; how they react to our assumptions,
• and have a clearer understanding of user preferences ready when we at last come to the table to discuss our new project with developers.

I’m going to try to post some more over the next few months, thinking about some of the ideas that are mentioned in Snyder’s book, and seeing what other people have written on the same topics. Some of the topics she covers include:

• an overview of the history and origins of Paper Prototyping,
• case study examples of how it might impact the design process and help a development team make important decisions,
• suggestions about the kinds of responses a good prototype (paper, or otherwise) should inspire, and the kinds of problems/confusions it should hopefully evade,
• guidelines for actually making and using a paper prototype - description of the actual materials used and providing ideas on how to clearly represent common interface features on paper,
• a walk-through of the process of actually performing a usability study: including how to pick a useful team - and useful users - and how to decide and design the tasks that user should be trying to perform,
• methods for capturing, understanding, and successfully reporting back on the study’s discoveries,
• discussion of common concerns raised about paper prototyping methods, and suggestions about when it’s most appropriate to use paper prototyping.

What do you think? Have you ever used paper prototyping, especially in the design of a library’s web interface? Do you have any further recommendations of good books / posts / articles to read about this technique?