Designing the Obvious, Part 5: Prototyping 101
Previous articles in this series have talked about how to know what to build, figuring out who your users are and understanding their needs, the creation of wireframes and storyboards, and how to write use cases to detail interactions quickly. Today, we’ll take a look at the many marvels of prototypes.
A prototype is essentially the interactive version of a mockup, through 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. As you’ll see in the next few pages, 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.
We’ll investigate the benefits of prototyping, the different approaches you can take to creating them, and the ins and outs of each approach.
Benefits of Prototyping
A prime benefit of a prototype is that it gives you something you can show clients (whether internal or external) that actually functions. Clients can click on interface elements, see what happens as a result, and begin to get a real perspective of what an application or site will do.
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 very expensive, and it takes valuable time and energy to make changes in a working application. Making substantial changes late in the game is what 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 make the change, so it doesn’t even interrupt a project. The simple fact that it’s 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 just 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 expensive coding.
If you’re lucky (or a really good prototype builder), you can even reuse your prototype interface in the final application. The key advantage to this technique is that you’ll have an interface in front of you throughout the entire development process, which will help limit the addition of new features later on, provide a clear picture of how the final project will work so everyone knows exactly what needs to be done, and give you a chance to work with the product directly from very early on in the process, so you can gradually refine it, step by step by step, until it shines. We’ll talk more about this possibility later in this article.
One last benefit of a prototype is that you can create usability tests 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 could be improved. In a future article, we’ll look at usability testing in more depth. For now, it’s only important to understand that testing can start with a prototype (or earlier, with wireframes) and still be very effective in gaining quality feedback.