The Goals of Prototyping

Most problems with prototyping stem from having the wrong goals or motivations. The odds of successful prototyping improve significantly if you have practical, realistic goals and use a prototyping technique that can accomplish these goals. Let's look at some good and bad reasons to prototype.

Good Reasons to Prototype

I consider the following to be good reasons to prototype:

• To resolve problems You need to understand and resolve a specific user interface problem.
• To visualize a design You need to visualize a specific user interface design.
• To help communicate a design You need help to communicate a complex or unusual user interface design.
• To obtain immediate feedback You need to obtain immediate feedback from users and other team members about a specific design problem.
• To design task flow You need to analyze the flow between the different user interface windows in a task and understand how the user will navigate between the windows in a task and between tasks. You might also need to determine whether the user is able to discover if a feature exists.
• To create a radically new design You need to create a completely different user interface design that uses new, nonstandard controls or new forms of user interaction. The more leading-edge your interface is, the more you need to prototype.

These goals have several attributes in common. The first is that there needs to be a specific objective—usually a specific design problem to be solved, a lesson to be learned, or a solution to be discovered. You shouldn't prototype for the sake of prototyping but instead to accomplish something specific. The second is that these goals do not necessarily require a functional prototype. You can use a nonfunctional prototype to solve problems, to visualize interfaces, or to communicate. Lastly, there is usually no need to prototype the entire user interface. You should prototype just enough to accomplish the goal at hand.

Sure, sometimes a full-blown, functional prototype that covers the entire user interface is warranted. If I were responsible for designing the next generation of the Microsoft Windows user interface, I would have no trouble justifying extensive prototyping of all the new user interface elements and the major system components. Without hesitation—no questions asked. After all, everything is new, the stakes are high, and the budget is there. But situations like this are relatively rare. Most programs simply don't have the type of problems that warrant such extensive prototyping. Rather, they have specific problems that justify specific prototyping.

Bad Reasons to Prototype

I consider the following to be poor reasons to prototype:

• To simulate progress The worst reason to prototype is to give someone the impression that that the program is further along than it actually is. Functional prototypes are an excellent way to fake progress.
• To create marketing demos If your marketing team asks you to create a prototype so that they can give a dog and pony show, recommend that they give a Microsoft PowerPoint presentation instead.
• To adhere to a rigid design process You have a design process where prototyping is always required, regardless of the need for it.