Industry trends in prototyping

Prototype is one of those words that can mean something different to everyone. Before I get too far along in a discussion of prototyping, it's probably worth exploring what I'm talking about. In the world of designing interactive products and services, prototype is generally defined as some representation of a design idea. In the world of physical products, the term tends to connote something quite similar to the finished manufactured form. Indeed, industrial designers use the term model to describe what interaction designers think of as a prototype.

Nomenclature aside, this process of representing the product that will ultimately be created is a core design activity. Henry Dreyfuss, one of the fathers of industrial design, gave much consideration to this activity in his classic book, Designing for People:

"Too much emphasis cannot be placed on the importance of three-dimensional models... When our ideas have been formulated, we design in clay, then plaster, finally in a material that will simulate the material to be used in manufacturing the actual product." (Henry Dreyfuss, Designing for People, pp. 61–62.)

In the broadest sense, all kinds of design artifacts are prototypes. Pencil sketches, blocks of wood, storyboards, wireframes, foam-core models, pixel-perfect state renderings, clickable demos, and functioning production code are all strategies for representing a thing being designed. However, in the world of interaction design, we usually reserve the term for ways of representing interactivity—not just the form but also behavior. For the purposes of this article, therefore, I'm going to focus on things that both look (at least somewhat) like the thing being designed and simulate a response to human actions (clicks, taps, selection, and navigation), even if the simulations are crude or fairly limited (see Figure 1).

For clarity's sake, it's probably worth mentioning that the term also implies a certain amount of disposability. Prototypes are meant to be a cost-effective way of experimenting with ideas. They are generally considered part of the pre-planning phase, rather than part of the construction or manufacturing process that results in the final product—although obviously the discoveries made during the process of prototyping should ultimately both inform and shape the construction process.

Reasons for creating prototypes

There are many reasons to create prototypes of interactive products or services. The activity of prototyping can aid in design exploration, evaluation, communication, and even construction. Because it can be a massive undertaking to create a single prototype that strives to achieve all of these goals simultaneously, it's important to be clear about your objectives. As Stephanie Houde and Charles Hill wrote in their seminal paper about prototyping, "What do prototypes prototype?" (PDF , 635K):

"Prototypes provide the means for examining design problems and evaluating solutions. Selecting the focus of a prototype is the art of identifying the most important open design questions. If the artifact is to provide new functionality for users—and thus play a new role in their lives—the most important questions may concern exactly what that role should be and what features are needed to support it. If the role is well understood, but the goal of the artifact is to present its functionality in a novel way, then prototyping must focus on how the artifact will look and feel. If the artifact's functionality is to be based on a new technique, questions of how to implement the design may be the focus of prototyping efforts." (Stephanie Houde and Charles Hill, "What do prototypes prototype?". Based on Houde, S., and Hill, C., "What do prototypes prototype?", in Handbook of Human-Computer Interaction (2nd Ed.), Elsevier Science B.V: Amsterdam, 1997.)

Reason 1: Prototypes make your designs better

Although sketches are a great way to start generating ideas, the best way to test and refine these ideas is to simulate the way a person will interact with the thing being designed. These simulations illuminate aspects of the user experience that aren't immediately evident and help designers understand how all the moving parts work together. In fact, the very act of creating a prototype can cause a designer to imagine a better way of doing things. As Tom Kelley of IDEO puts it in The Art of Innovation:

"Call it serendipity or even luck, but once you start drawing or making things, you open up new possibilities of discovery." (Tom Kelley, The Art of Innovation, p. 109.)

It is no coincidence that Apple, a company with a significant commitment to design, is also renowned for its reliance on prototyping. According to Leander Kahney, a journalist who has followed Apple closely:

"It's a process where they discover the product through constantly creating new iterations. A lot of companies will do six or seven prototypes of a product because each one takes time and money. Apple will do a hundred—that's how many they did of the MacBook. Steve Jobs doesn't wake up one morning and there's a vision of an iPhone floating in front of his face. He and his team discovered it through this exhaustive process of building prototype after prototype." (See iPhone pre-launch: Looking "Inside Steve's Brain".)

This clearly contradicts the popular (mis)conception that great ideas spring fully formed from the minds of great designers. Although it takes someone having that first spark of inspiration, great products are really culminations of the thousands of smaller, good ideas that came together to create a smooth, comprehendible, and compelling user experience. It is difficult to consider, let alone harmonize, all of these tiny parts without analyzing simulations to determine how a person will interact with them.

The Apple approach illuminates a very critical point: prototyping and simulation free designers to try something that no one has ever tried before. Even when we are struck by a compelling new idea, we are rarely confident enough to rush out and spend millions of dollars building it into a product or website, risking the quality of our user experience on a hunch. Sometimes designers may feel that they just "know" something is right, but this is often because they are experienced enough with the concept and usage context to run mental simulations, which in itself is a kind of prototyping.

Another important benefit is that prototyping helps designers fail faster. It is rarely the case that the first answer that occurs to someone is really the best solution. Prototyping helps designers evaluate ideas quickly and throw out the bad ones. At IDEO, they put it this way: "Fail early to succeed sooner." At Cooper we say, "Reality bats last." (Apologies to non-US readers for the baseball bat reference.) Sometimes even watching a bad idea bang into the hard edges of reality can provide a new perspective on the problem at hand, and can uncover some good ideas in the process.

Prototypes also provide extremely valuable insight into transitions between state and more dynamic interactions. Interactivity is about behavior—how a product or artifact changes over time in response to user input and events in the world. While the traditional model of software and web interactivity typically replaces one application state by another—as in a slide show, the iPhone, Ajax, and other contemporary user interface (UI) frameworks—the transitions can be more animated and full of motion. The days of replacing one screen with another are over—and certain interface elements may grow, change, and move. Getting these behaviors just right makes prototyping especially critical to the design process.

Reason 2: Prototypes facilitate communication

Interaction design is about much more than just having good ideas—it's about expressing a vision, working with people to chart a path forward, and then ultimately executing on that vision. This means that designers have to convey the ideas in their heads to others. One of the most challenging things about this is the fact that while designers are quite skilled at inferring the behaviors of a whole system from a few flat images of a user interface, most other people are not. The benefits and implications of your carefully crafted designs may be lost on engineers, product managers, marketing folks, and executives unless you are clear, persuasive, and compelling in your explanations. Prototypes can help communicate the requirements and goals you are striving to deliver.

In his book Designing for Interaction, Dan Saffer puts it this way:

"Many clients will have difficulty understanding a design until they see and use the prototype. Like all the other models and diagrams, it is a tool for communicating. Prototypes communicate the message, 'this is what it could be like'." (Dan Saffer, Designing for Interaction, p. 114.)

The goal with a communication prototype is to help your audience understand your vision and concrete ideas on both an intellectual and emotional level. Telling project stakeholders about a particular dynamic interaction is much less informative (and less compelling) than allowing them to experience it. When you're shopping for a car, hearing that a certain model has a sporty ride might pique your interest, but you're going to want to drive it yourself before you actually buy it.

Additionally, one of the most important conversations that a designer engages in is with the engineers responsible for building the product or website. Designers should give engineers very clear directions regarding not only the form (the layout of each screen) but also the behavior (how the item responds to user actions and even the feel of these responses). While words and pictures are a good, low-bandwidth way to communicate these goals—especially when they are presented in a narrative format, as I'll discuss later—there are situations where animation is required to help engineers understand your vision of how an experience should happen.

Transitions between states are a great example here. A good part of the iPhone's magic is the animations that happen when a user interacts with the touch screen. Many small animations are hardly even noticed by most users, but together they contribute to an overall sense of responsiveness and dynamism, ultimately making a simple tap or gesture feel more satisfying and enjoyable. These animations take a lot of work to get just right—don't assume that waving your hand and saying "you know, wipe it from left to right" will give your development team everything they need to build a compelling experience.

Ethan Eismann of the Experience Design (XD) team at Adobe does a nice job explaining in Adobe AIR and the experience brand how, among other things, animated transitions can improve the experience of using your product or service.

Reason 3: Prototypes enable user input and usability assessment

Informal user feedback sessions and more formal usability tests are a great ways to figure out if your product or website has major usability problems—as well as to refine things like button labels and visual hierarchy. Some people feel strongly that such sessions can be conducted with very low-fidelity prototypes—such as Carolyn Snyder, who wrote Paper Prototyping, a fantastic book on the subject. Others, including myself, find user feedback to be most useful when people are responding to something that looks and acts like a finished product. Though to be entirely clear, this should not be interpreted to suggest that this kind of user feedback should be scheduled at the end of the design phase. It's absolutely necessary to schedule sufficient time following your user feedback sessions to adjust your designs to accommodate and integrate what you learn.

What seems to be largely agreed upon is that it's a good idea to get your design ideas in front of people who are similar to the target audience that you hope will eventually use your product or website. This is another good reason for creating prototypes that simulate aspects of your design in order to gather feedback.

Reason 4: Prototypes help assess technical feasibility and reduce development time

Renowned design theorist and social scientist Donald Schon famously described design as "a conversation with materials." By this he meant that as a designer comes up with an idea and begins to simulate how it will be constructed, she will learn new things about the forces acting upon the situation and change the way she thinks about the problem, thereby evolving her sense of the solution. Although this kind of prototyping can start to bleed into a technical proof of concept, this isn't always a bad thing. It's not just about figuring out the hypothetically ideal experience for your user audience, but more importantly, it's about figuring out the ideal experience that can actually be delivered to that audience, given a certain technical environment and development timeline.

Delivering technically infeasible designs to your development team is the equivalent to giving someone driving directions to a dead end. They are pretty much guaranteed to be late, if they arrive at all. First they will try to build what you've delivered, discover the impasse, and then be forced to find a new route. This adds significant time to what is already likely to be an aggressive development timeline. If, on the other hand, you work with developers to prototype questionable interactions, everyone on the team will be more confident about what it will take to deliver what you've designed.

In many cases, you may be working with well-known technical parameters. If you've designed hundreds of web applications and you're not pushing the envelope in terms of interaction idioms, you probably have a pretty good idea about what is and what is not technically possible. In this case, prototyping may not be necessary. However, if you're working in a new technology, or trying to invent input or display mechanisms, building a proof-of-concept prototype can be a very wise move, especially if the development team would also benefit from the creation of a prototype.

Popular approaches to prototyping

Depending on the goal you're trying to achieve, there are a number of ways to go about creating a prototype. Rather than providing a recipe or getting into intricate technical detail about each method, I'll provide some patterns and trends describing the strategies that interaction designers use to effectively simulate the user experience at various stages in the design process.

Storyboarded scenarios

The first approach to prototyping comes from the movie industry. As part of planning and preparation for filming, an artist typically creates a comic strip–like sequence of images to accompany a script. This helps the director, cinematographer, and special effects team visualize how the scenes will play out, plan shooting schedules, and anticipate problems.

Many interaction designers use a similar technique to make sure their designs hang together. This is an absolutely vital part of the way we work at Cooper. Designing a single screen state is a sure recipe for clunky interactions. Instead, we start with a scenario (or story) about a persona (or user archetype). Before we even draw a single picture, we imagine the ideal experience from a narrative perspective (kind of like writing a screenplay). We then create sketches to visualize this experience at each step in the narrative (see Figure 2). In some cases, depending on what we're designing, these sketches are of a physical environment like an office or an airport. In other situations they're limited to just an onscreen user interface, such as a web application or some software products.

We typically start with rough sketches to approximate placement and orientation of things, as well as represent the most significant interactive behaviors. We often show roughly storyboarded scenarios to clients and developers as a way of communicating our initial concepts. While this may not meet everyone's definition of a prototype, I would argue that this is actually one of the most effective prototyping tools at a designer's disposal. It is easily the fastest way to communicate an interactive design idea.

While pen and paper can be a perfect medium for creating storyboards, we've found that the combination of a Wacom tablet and Adobe Fireworks CS4 allows us to work even more quickly and efficiently. At Cooper, we use Fireworks as our primary screen rendering and production tool for work from sketch to final graphic assets. (For more about how we use Fireworks, watch the video and read the companion article by Nick Myers, Designing interactive products with Fireworks.)

To create a sketchy storyboarded scenario in Fireworks, we typically rely on the States panel (formerly called the Frames panel) to represent each state in the scenario (we like the new name). We use layers, shared across states, and symbols to reuse screen elements, eliminating the need to draw the same thing over and over again. Depending on your skills and how you like to work, you can either hand-draw things using a tablet or rough them out using vector objects with stroke treatments and Live Filters in order to give them a looser feel. Alternately, depending on your target audience, you could use the black-and-white wireframe approach. However, my personal experience is that wireframes are not quite as expressive as a sketch and can be more difficult to understand in a moving narrative.

Sometimes we take these storyboards to a more refined level for presentations where we really feel that it's important to express the vision in a compelling way. Using photography or more refined illustrations with a strong narrative can really bring design ideas to life in a way that even detailed screen renderings may not. We find this approach to be particularly useful when we're designing products or services that are used away from the desktop, such as in mobile or medical settings.

Storyboarded scenarios can be useful tools for planning other kinds of prototypes, too. As you begin the creation of more interactive prototypes, it's often useful to sketch out several scenarios in order to make sure you're creating the right kind of interactivity.

Paper prototypes (and crude physical models)

Another popular approach to prototyping interactive products and services involves using different sheets of paper or cards to represent different screen states (see Figure 3). Some paper-based prototypes even rely on pop-up book techniques to provide basic interactivity like scrolling text or menus. This kind of prototype is primarily used to present design ideas to prospective users in order to identify areas that require further refinement.

This approach can be used to prototype computer-based interactive products and services, as well as other form factors and input methods. It is common for industrial designers to create rough models out of foam, clay, or even use 3D printing (and other solid freeform fabrication techniques) in order to assess ergonomic factors and to get potential users' reactions to various shapes and physical controls. It can be particularly useful to combine a rough model with some printed screens to get feedback on design aspects, such as type size and mappings between physical controls and the screen.

As I mentioned earlier, Carolyn Snyder's book, Paper Prototyping, is the definitive source on both creating paper prototypes as well as using them as a way to perform usability testing. Her suggestions offer valuable insight into gathering user feedback based on design concepts. I highly recommend her book to someone creating any kind of prototype; many of the important considerations are similar, regardless of the level of fidelity and responsiveness.

My personal experience is that while rough mockups, including paper prototypes, can be great for obtaining user feedback to high-level design concepts, actual standardized and quantified usability testing using rough renderings is unreliable and not terribly useful. The problem here is that appropriate visual design has such a significant bearing on the readability and usability of a user interface that your results may have as much to do with how well you can sketch as how good your design ideas are. Less formal methods can be useful, though, especially when creating prototypes for technical or medical products. Walk a potential user through a paper prototype of proposed ideas and ask them questions about how they're interpreting what they're seeing and how they would respond to certain situations. This strategy can help you identify rough spots and areas where users become confused.

Conventional wisdom states that paper prototypes are hand-drawn and put together with glue sticks and Post-it notes. While this certainly works, using Fireworks to crank out a number of screen element permutations to reflect possible screen states can save you a lot of time and effort. Once again, I recommend using layers and symbols to reuse components. Use the States panel (or Frames panel) to organize interface states (see Figure 4).

Clickable prototypes

This kind of prototyping attempts to simulate the user experience of the final product most closely. The goal here is to create something that responds realistically to user input. Sometimes this interactivity can be limited to clicking (or tapping) buttons, links, and other controls—as is often the case with a website. Other times, in order to create a realistic simulation, mouse drags, keyboard interactions, or gestural input must also be considered. Figuring out what interactivity to simulate requires examining what open design questions you need to answer. If you're proposing a novel gestural interaction, it's risky not to prototype, test, and refine it in several iterations. If you're working with stock controls in common patterns, you can probably avoid prototyping each interaction.

In addition to figuring out what interactive behaviors to prototype, there is the question of how visually refined the prototype should look. My personal experience has taught me that the more the artifact looks like a finished product, the better the simulation. Again, ask yourself what questions you're trying to answer with the prototype. If you're trying to figure out the appropriate size of click targets on a touch screen, a polished visual style probably isn't necessary. If you're assessing the effectiveness of various animated transitions, you might want to consider how these animations work by generating graphics that are representative of the final user interface.

There are various approaches to actually building the prototype, depending on what you want to simulate. The simplest and fastest often involves stringing together a series of bitmaps, each representing a screen, view, or state of the application or website. After storyboarding the state variations we want to include, and rendering the prototype in Fireworks, we usually use Dreamweaver or Flash to build out simple navigational links between "canned" states (see Figure 5).

Obviously, the kind of interactivity that you can simulate in this fashion is somewhat limited, but this is a great way to assess the effectiveness of information architecture, navigational constructs, screen organization, and major behaviors. I should note that the as-yet unreleased Adobe Flash Catalyst (formerly referred to as Thermo) has been designed to integrate with Fireworks and Photoshop in order to greatly reduce the amount of time and effort required to build interactive Flash prototypes. This could provide a very effective way for interaction designers to fit into developer workflows.

Past a certain point, it becomes pretty challenging to fake interactivity without writing a bit of code. It's beyond the scope of this article to get into specific details here, but suffice to say that there are a number of different platforms and tools you can use to create interactivity. In the world of HTML-based web applications, we've had success working with JavaScript libraries, including Ext JS and script.aculo.us, which are both strong foundations for building Ajax-style interactivity. If you're looking to be a little more adventurous with your interactivity, or if you're more familiar with Flash than HTML, Adobe Flex is a great option—it's well integrated with other Adobe tools and supports robust and dynamic interactivity (well beyond what can reasonably be achieved with HTML and JavaScript).

Finally, if you're designing for an established platform like Microsoft Windows, Apple Mac OS X, or Apple iPhone and you know you want to use stock controls, you may be best served working with a language capable of using that platform's APIs, such as Visual Basic or C# (Windows) or Objective-C (Mac OS X and iPhone). If this is the case, I'd strongly suggest that you begin by generating storyboards—because the second you start looking into your IDE, you'll be tempted to start worrying more about coding efficacy than user experience. Of course, as I mentioned previously, it's possible to have a healthy balance between the two.

Where to go from here

Design is about imagining a better future and figuring out how to achieve it. Prototyping can have an important role in both of these activities, but it is not an end in itself. If you're honest with yourself throughout the design process, you'll notice a lot of nagging questions in the back of your mind: "Will users really be able to figure this out on their first use?"; "How should we transition between these two contexts?"—and so on. When you find yourself in such a quandary, think about whether a small amount of prototyping would help to shed some light on the subject.

Of course, all this prototyping takes time and effort. As such, it can be expensive. You may find yourself wondering whether this is money well spent. As with all design activities, it can be difficult to specifically calculate the ROI of prototyping. Two of the benefits to prototyping I discussed ("Prototypes facilitate communication" and "Prototypes help assess technical feasibility and reduce development time") result in project efficiencies, which will vary by project and team but should be measurable, given enough trials.

The other two benefits ("Prototypes make your designs better" and "Prototypes enable user input and usability assessment") influence the core of the experience you deliver to your customers and users. It is difficult to break down the benefits of a commitment to design into the ROI of specific activities. It's impossible to say precisely what amount of Apple's success is due to its significant expenditure on prototyping. What is obvious is that they wouldn't be able to deliver the same pleasure and loyalty-inducing products to the market without this activity. That alone should be enough to motivate you to figure out how your design activities can benefit from prototyping.

To learn more about how Fireworks can increase your productivity and simplify your workflow, visit the Fireworks Developer Center. There you'll find articles, tutorials, and sample files. Also watch the videos on the Fireworks channel of Adobe TV, such as Creating interactive prototypes for reviews and Rapid prototyping.