A prototype is essentially the interactive version of a set of wireframes, by which other people can see how an interaction might work, how they might navigate a site to get through a series of screens, or how a particular widget, such as a drag-and-drop shopping cart, might behave. Prototypes come in varying degrees of quality, and it doesn't really matter how you build your prototypes, how nice they are, or whether they're exact simulations of a future design. What matters is that they demonstrate how something should work to some reasonable degree of accuracy.
The prime benefit of a prototype is that it brings to the surface all the instances where the system's logic is dictating how a design comes together (plus it gives you something to show clients and coworkers that actually functions). Clients, and you, can click on interface elements, see what happens as a result, and begin to get a real sense of what an application or site will do. This makes it quite simple to spot implementation models in a design, because they're right in front of you and there's no way to escape them. And seeing them is the first step toward getting rid of them.
In addition to giving clients something that they can touch and use, a prototype can be used to solicit feedback about an interface before you get too deep into the process to make adjustments. Writing code is expensive, and it takes valuable time and energy to make changes to a working application. Making substantial changes late in the game causes missed deadlines and overblown budgets, but changing the entire behavior of an interaction in a prototype is fast, cheap, and easy. And usually it only takes one person to build and maintain the prototype, so it doesn't even interrupt a project.
The simple fact is that a prototype allows you to get valuable feedback and put it into action immediately to see how the new version is received. If people don't like the next version of the prototype, you can easily change it again. In fact, you can change it several times in a matter of hours, exploring different solutions to each problem the prototype is meant to address, and nail down a final solution before getting into coding.
Another key advantage to prototyping is that you have an interface in front of you throughout the entire development process, which helps limit the addition of new features that might obscure the basic purpose of the tool and therefore impinge on the user's mental model. It also provides a clear picture of how the final project will work so everyone knows exactly what needs to be done, and it gives you a chance to work with the product directly very early in the process so you can gradually refine, step by step by step, until it shines.
Note, however, that it's best to avoid using prototype code in a finished application. Prototype code is generally hacked together in a very short period of time and usually doesn't provide the scalability needed to create a stable application.
One last benefit of a prototype is that you can create usability tests around it early in the development process. As long as your prototype clearly shows what will happen at each step in a process, you can run it past some actual users and find out very quickly what problems exist, what questions come up, and what can be improved. We'll talk more about testing your application later in this chapter.
There are quite a few ways to create a prototype, and each style has its own pros and cons. Following is a breakdown of some popular prototyping styles.
A paper prototype is made up of interface elements sketched on different pieces of paper so that various application states and screens can be shown without redrawing the interface each time. A paper prototype can be used for early usability tests by having one person act as the computer and another as the test moderator. The user "clicks" (touches) the parts of the interface he wants to interact with and the person acting as the computer manipulates the paper sketches to show what would happen in the application as a result. To learn more about paper prototyping, pick up Carolyn Snyder's book Paper Prototyping: The Fast and Easy Way to Design and Refi ne User Interfaces (2003), and read every last word.
HTML prototypes are Web pages put together without regard for color, fonts, or anything else that qualifies as a detail. The goal is to simply get the major elements of a screen into a basic HTML format and have users test it out to see if they understand the application's basic purpose and flow and interaction model. Various WYSIWYG (what-you-see-is-what-you-get) editors like Adobe Dreamweaver can be used to create these incredibly stripped-down versions of application screens in very little time, and it's a great way to see how an application might really work once it's completed so you can rapidly shape it into something that supports a user's mental model.
A click-through mockup is a series of mockups that illustrate various application states or screens, each of which has triggers (such as a button) to transport the user to the next screen and illustrate a basic task flow. Prototypes like this are great for illustrating a single course of action, but aren't always very efficient for simulating multiple interactions within a single interface, or multiple states within a single screen. In other words, it might be nice to use a click-through mockup to show the progression from one step in a paginated form to the next, but you probably wouldn't want to use it to demonstrate a page with multiple possible actions, each of which leads to different screens. Stick to showing off a single interaction rather than trying to create something as dynamic as what you might be able to show with a more robust prototype. Still, click-through mockups can help you see where implementation models are being used so you can change things now instead of later.
Flash is a fantastic tool for prototyping, but only if you know your way around ActionScript and can whip up interfaces quickly using the UI Component Set that ships with the authoring tool and any prototype elements that need to be built from scratch. If you're willing to dive in, or already have some Flash skill, it's definitely worth testing to see if it's right for you. Create a prototype for something simple, such as a contact form, and see how far you have to take things to create an effective sample. The benefits you gain from the rich interface capabilities of Flash can outweigh the extra time you'll need to create prototypes with it.