steve kwan user experience designer

Low-fidelity prototypes

(March 13th, 2005 - 10:12AM)

COMP 7021 - the course I'm taking at BCIT - recommends the use of low-fidelity prototypes when attempting to gain user approval for a website.

For those unsure, here are some terminology definitions:

• A prototype is a mock-up of a website or software product where the look and feel is being demonstrated, but the actual functionality has not yet been added. The purpose of such a prototype is to demo your interface to your boss or client and gain approval before you begin developing the underlying structure of the website/product.
• A high-fidelity prototype is a prototype that is developed in "soft" format on your computer. For example, developing an interface in Visual Studio .NET, but not developing any underlying code, gives you a high-fidelity prototype.
• A low-fidelity prototype is a prototype that is developed in "hard" format using pencil and paper. Computers have not been used to develop these protototypes.

The textbook for this course recommends we use low-fidelity prototypes. That's something that I just don't see myself doing.

Perhaps low-fidelity prototypes were a good idea back in the days when creating high-fidelity prototypes required a decent amount of work. But with tools like Dreamweaver and Visual Studio .NET, creating high-fidelity prototypes is easy. In fact, it's not much more work than creating low-fidelity prototypes.

Plus, if you're demonstrating a potential interface to a client, using a low-fidelity prototype will make you look stupid. If you're a software engineer, people expect you to be an expert in your domain. If you're resorting to pencil and paper for your demos, you're not going to look like much of an expert.

The textbook suggests you assign a person to play the role of the "computer" when showing low-fidelity prototypes to a user. Instead of using the mouse to navigate the prototype as the user would do in a high-fidelity prototype, the user simply looks at a paper prototype and instructs the "computer" to click a certain menu item, etc. This seems a bit awkward to me. I envision a low-fidelity prototype demonstration going something like this:

Engineer: "Okay, we're going to show you a series of paper prototypes which represent your interface. You'll navigate these pages as if they were part of a software product."

User: "Hold on...aren't you guys software developers? Why didn't you make your prototype on a computer?"

Engineer: "We read in a textbook that doing it on paper was a good idea. Anyway, Bob here will be playing the role of the computer. You will interact with Bob like you would interact with a computer. If you want to select an item from the paper-based prototype, tell Bob and he will display the results of your action for you."

User: "Sure..."

Bob: "Oof!"

Engineer: "Please don't double-click Bob's nose."

I really don't think low-fidelity prototypes are all that useful now that we have effective high-fidelity prototyping tools available. Maybe I'm missing something, but I thought one of the purposes of using computers was to move away from paper.