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.
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)