Why I'm Not Doing a Paper Prototype

June 5, 2007 ⋅ 2 Comments »

A low-fidelity prototype is a quick-and-dirty way of doing usability testing for software. It’s often referred to as a paper prototype, because it’s usually done by sketching the interface out on paper. The point of it is to get feedback from real people very early in the design process. Because paper prototyping can be done so quickly and cheaply, you can iterate through a bunch of different designs in a short amount of time.

Paper prototypes

Low-fidelity prototyping is generally accepted to be a “best practice” in software design. But even its strongest supporters admit that it’s not appropriate for every situation. In her book Paper Prototyping, Carolyn Snyder says: “Paper prototyping’s main strength is depth—the human Computer can simulate much of what the interface will do.”

This is an important point: low-fidelity prototypes are really about what, not how. Working on my research in the past month, I felt like I should be doing some paper prototypes; but I also had a sense that they wouldn’t really be that useful. And now I realize why: when you are designing new interaction techniques, the how is often the most important part. How does the system respond to the user? Does it feel responsive? Does it feel natural? Is it cumbersome or repetitive? These questions are hard to answer with a low-fidelity prototype.

Also, certain types of software just aren’t suited to being tested with fake data. For software that is designed to integrate with your everyday life — like an email client or a search tool — it’s hard to create a prototype that will be a good simulation of the real-world use cases. Not only could a low-fidelity prototype be unhelpful in these situations, it might actually be a bad thing, since you would be making design decisions based on flawed data.

(Photo from Kables on Flickr)

2 Comments:

  1. e - June 6, 2007:

    Can't you do a lo-fi prototype with real data culled from a real data source?

  2. Patrick - June 6, 2007:

    Well, yes and no. For an email client for example, the test subject would need to allow me to read their email, and use it in the paper prototype. That makes it difficult. And then I would need to simulate the kinds of email they would typically be receiving (or actually monitor their inbox). For something like a search tool, because the use is so open ended, there is almost no way that you could prepare a paper prototype for a realistic use case.

    And as I mentioned, when you are looking at interaction techniques, instead of specific applications, the most important part is often the exact thing that paper prototyping leaves out -- the really subtle "this feels right".