Skip to Navigation | Skip to Content


A Practitioner’s Guide


The What and Why of a Prototype

Please note: we're pleased to provide an early taste of Todd's writing; a "formal" sample chapter is forthcoming.

A prototype is a conceptual model that captures the intent or idea of a design.

Earlier this year, while conducting a user experience training workshop, I asked “What is a prototype?” Most of the participants were user experience practitioners somehow involved in software design or development. So, it wasn’t surprising most of the discussion revolved around “a working model of the final product.” What was surprising was the response to my next question, “How many of you have ever built a prototype?” Only one person raised a hand.

Let’s start by addressing the question of “What is a prototype?” Don’t worry, I promise to address the question of why more people aren’t prototyping later on in this book. But for now, let’s address the question of “What is a prototype?” Well, the participants had it mostly correct. A prototype is a conceptual model that captures the intent or idea of a design. Prototypes are often incomplete.

Now, you may have noticed I have left the word “working” out of my definition. This is intentional. The term “working” can be defined many ways, but is often interpreted to mean functioning. This becomes a problem when you’re using it to define a prototype.

Architect Frank Gehry is known to sculpt his conceptual designs using materials rather than draw them using a software program. He feels this enables him to design freely, whereas a software program would limit his creativity. These miniature models may not be functional in the sense of having working elevators, but they clearly work as a method to capture his ideas and communicate his vision.

The benefits of prototyping

Prototypes are a great communication tool for fleshing out design ideas, testing assumptions, and gathering real-time feedback from users. There are a number of things you can communicate through a prototype. Traditionally artifacts like a wireframe sketch, while effective for communicating behaviors to designers, developers, and management, are not the most effective vehicle for communicating and testing a design with users.

1. Communicating a design concept

If a picture is worth a thousand words, than an interactive prototype is worth 10,000. Prototypes have the power to show, not just tell. As AJAX and other rich applications continue to grow, the need for prototypes as a design communication tool increases.

Recently, I was discussing a particular design solution for providing system feedback with a client. The concept is pretty simple and is commonly referred to as the JavaScript yellow fade technique. After trying to describe it, the client responded “Can you show it to me?”

So, I put together a quick animation showing the fade technique between the screens below using Keynote. The first screen highlights the focus area. Then over a few seconds, the highlighted area fades to white as seen in the subsequent screens.

Once the client saw the transition between the two screens, they instantly got the concept.

2. Making design decisions

In 2005, my company, Messagefirst, was working on a new product for Comcast – the Comcast Digital Voice Center (DVC). The Comcast DVC is an application which allows customers to access voicemail and manage calling features using a computer. Sounds a bit strange, I know, accessing voicemail using a computer. However, there are some real world benefits.

Let’s take Lisa for example. She likes to have her home phone forwarded to her mobile phone during the day. Now, with a traditional phone service she has to call a number, if she can remember it, listen to a series of prompts, one after another, and setup forwarding on her phone. It’s very inconvenient and time consuming. With the DVC, Lisa launches her web browser, clicks on the DVC bookmark, and quickly selects the “Enable Quick Call Forwarding” feature on the main screen. That’s it, she’s done. No trying to remember a number. No waiting through a series of voice prompts. Oh, and if she wants she can listen to a voicemail while she’s there, she can pick any one she wants. She doesn’t have to wait to listen to all of them. She simply picks the one she wants and plays it. Quickly. Easily.

As you can imagine, this new product had some innovative and unfamiliar features. Using a phone is pretty common. However, accessing and managing calling features from a computer was at the time evolutionary – the entire concept was new and different. This meant we faced a number of design challenges.

In many cases, a problem has more than one possible design solution. Deciding which design solution is best can be difficult. We’ve all been there. Marketing has their idea they’ve already sold to the Management team in a PowerPoint presentation. The Design team has another idea and doesn’t want to be stuck using what was in the presentation - they want it to be really sexy and cool. The Usability team wants to stick to conventional standards. The Engineering team wants to build whatever will require them to write the least amount of code. And the Management team doesn’t really care what design is used, as long as it’s ready for that trade show that’s coming up in a few weeks. Everyone has their own idea of the right design solution. So, how do you decide who’s right?

Create a quick prototype of the different design solutions. Put them in front of the other team members and get their feedback. Use the prototype as a tool to make design decisions.

Don’t just talk about the ideas, show the different design solutions. Prototypes don’t have to be fancy. They can be a few storyboards on paper to show the different states of the design. Or they can be an animation done with Flash, PowerPoint, or Keynote. Or, if you’re feeling really adventurous, they can be done with Flash or HTML to let your team members interact with the prototype. I’m not going to get into the different methods too much right now, as that’s discussed under “Methods and Tools” this book.

Okay, back to the design challenges we faced. One feature of the DVC is the ability to have dozens of speed dial numbers. The traditional method for allowing someone to store dozens of numbers would have been to give them dozens of input boxes on the screen. They enter the numbers for one or more speed dial entries and save it. Well, I’m a huge fan of clean design and simplicity. If you don’t need it, delete it. And to me, having dozens of input fields for phone numbers on a screen isn’t exactly my idea of clean design. So, I came up with a different concept – a method to dynamically add more fields on demand.

This concept would allow customers to show only the number of input fields on the screen they needed, while enabling them to add more fields on demand. Sounds pretty simple, right? There was a catch. I didn’t want customers to have to wait a page reload when adding another input field. This made the Engineering team cringe. Impossible.

That’s when I showed them this:

Add Input Field (prototype sketch)

Seeing the prototype sketch, they understood the concept. However, several members of the team were convinced it wouldn’t be intuitive or work at all. They suggested we just use static fields. It might not be as clean, but it would be easier to to build. Whichever model we chose, it would be used throughout the application. So, it was important we picked the right one.

Now we had a design decision to make. Do we use a model based on Rich Internet Application (RIA) techniques that’s cleaner and simpler? Or do we stick to the old method that’s easier to build, but not as clean? Is one more intuitive than the other? Do users have a preference? Does one perform better than the other?

We decided the best way to make this decision was with direct customer input. And the best way to get this input was with a prototype. After all, if we were having a hard time communicating the concept to each other with sketches, imagine how difficult it would be to communicate this concept to customers. And the last thing any of us wanted was launch a design that customers could not understand or use.

We created a set of paper prototype and performed A/B testing with eight participants. For each participant, we gave them a series of tasks that included adding a field using the more traditional model of static fields on the page and the new model, which allowed them to add fields on demand. Half of the participants were shown the traditional model first, then the second. The other half were shown the reverse. We wanted to reduce bias and make sure we tested for multiple activities like: adding a new contact, adding additional phone numbers and email addresses to a contact, and adding speed dial numbers.

Every participant preferred the clean design of the on demand model. And as for our concerns that it wouldn’t be intuitive – they quickly vanished. Every single participant entered information into the text field, selected the “add” action, and watched as we simulated the new field appearing.

Prototyping allowed us to communicate our concept and make data-driven design decisions.

3. Testing design concepts

In the world of redesign, there are two models – the day at the spa and the extreme makeover.

The day at the spa is the same face, just a little fresher. Maybe you add a few new features, make a few enhancements, fix a few things, but overall, it’s still the same face, same design. It’s really more of a realign than a redesign.

The extreme makeover, however, is an entirely different animal. You’re breaking new boundaries, trying radically new ideas, new design concepts. You’ve got a new face, shed a few pounds, modeling new wardrobe – your friends might not even recognize you anymore. This can either be really good, or a complete disaster.

Before launching an extreme makeover, you need to test it. And what better way to test your design concepts than to put them in the hands of your customers? This is exactly what one of our clients, IntraLinks, did with their extreme makeover design.

A little over a year ago, we performed usability testing on their application. Armed with a list of what was working, what wasn’t working, and some recommendations, the Design team at IntraLinks went to work. A year-and-a-half later, they had a functional high-fidelity RIA prototype and called us to help them test it.

I have to say, this was one of the most well designed prototypes we’ve ever had the opportunity to work with. The Design team at IntraLinks had made a radical shift from a web-based application that behaved like a portal to a web-based application which behaved like, well, an application.

The old design was very page-based – click a button, the page refreshes, do something and click another button, page refreshes again, click another button, page refreshes again. It wasn’t necessarily broken, just outdated and inefficient. The new design, however, used a semi-stateless screen-based model often referred to as a RIA. This design was full of modern day features like drag-and-drop, right-click, contextual menus, and auto-update.

You might be wondering “If it sounds so great, why did they test it?” Well, because it was a radically new design concept for them. In fact, it was several radically new design concepts. They wanted to see how their customers would react. Some of their current customers had been using the same version for over five years. Even though this new design was “better,” if their customers couldn’t use it, launching this new design could be disastrous.

First, as with any extreme makeover, they wanted to see if they had done any harm. If they hadn’t done harm, but had in fact improved it, how much had they improved it?

Second, they had a number of burning questions. Could customers get these new concepts? Would customers discover drag-and-drop? What about right-click and contextual menus? If they used these features in one area of the application, what other areas did they expect to use them? Which concepts don’t work, or simply need some improvement?

Considering this radical shift and their questions, a functional high-fidelity prototype was the best way to test the design concepts before launching the product.
Overall, participants responded very positively to the new design. Several commented it reminded them of their other applications. Many of the interactions, while different from their current IntraLinks, were familiar due to the similarity with Windows Explorer, Outlook, and other applications. The IntraLinks Design team was leveraging this existing knowledge built from interactions with other applications for their new design.

About half of the participants discovered rich features like drag-and-drop, right click, and contextual menus. Those who discovered these advanced features, seemed to expect them from such a polished application. Those who didn’t simply didn’t expect to be able to do that type of interaction using a web-based application. However, once they were shown, they were delighted and began looking for it throughout the application.

The prototype and testing was a huge success, validating many of their design decisions, proving they could successfully make the jump from portel-like to application, and providing valuable insights into additional new design concepts for system messaging and multi-state transactions.

Post a comment

We’ve enabled comment moderation on Rosenfeld Media. Upon posting your comment, it will not immediately appear on this page. Hang tight, we’ll be sure to screen it before too long. (Starred fields are required)

We don’t like these either (but comment spam makes them a must)

Buy This Book:

Ordering, Shipping & Return Info