Prototyping is the best way to explore a design, determine how well it works, effectively communicate the design to others, and test the design with users. Over the past few years, we’ve seen an explosion in new prototyping tools that allow you to simulate sophisticated interactions quickly and easily. Yet, despite these technological advances—and sometimes because of them—UX designers still make the same common mistakes when creating prototypes. In this column, I’ll discuss some of the most common prototyping mistakes designers make and how to avoid them.
Jumping Too Soon into Prototyping
One of the most common mistakes is jumping too soon into creating a prototype before sufficiently thinking through and planning out a design. This problem is especially common among those of us who aren’t very comfortable with the messiness of sketching. It can be tempting to open up a prototyping tool, assuming that it would be easier to work out the design on the screen.
However, most prototyping software supports a more detailed level of design than sketching. Even tools that create black-and-white, wireframe prototypes still cause designers to focus at a more detailed level—on layout, alignment, fonts, and interaction details—before having thought through the high-level design concepts. You can get caught up in putting more effort into a single design direction rather than trying out multiple design options at a high level.
To resist the urge to prototype too soon, do the following:
Sketch high-level design concepts on a whiteboard. The great thing about sketching on a whiteboard is that you can’t easily draw straight lines, align or size elements correctly, or create text in the correct font size. Because sketching is so crude, you don’t get caught up in providing too much detail. The format forces you to focus on high-level design concepts.
Explore various design possibilities before prematurely settling on one design direction.
Sketch more detailed page-layout options on paper before beginning work on a digital prototype.
Sketch out each of the main page types before prototyping. It’s often tempting to begin prototyping once you have the first screen type sketched out. The danger is that you might not go back to sketching when you need to create new screen types. Instead, you may design them in the prototyping tool.
To quickly test your high-level design concepts, create and test paper prototypes before using digital prototyping tools.
Failing to Plan What to Prototype
When you are ready to begin prototyping, it’s tempting to simply begin creating the first screen, without really thinking about which screens and interactions are most important to build out in the prototype. In the latest prototyping tools, it’s so easy to build out screens and simulate interactions that you can find yourself getting caught up in creating all of the screens, functions, and interactions, without thinking about which elements it’s most important to spend your time on. In addition to wasting time, creating too many unnecessary elements and screens makes your prototype overly large and complex, making it much more difficult for you to keep track of what you’re doing and to make changes.
To avoid aimlessly creating unnecessary screens and elements in a prototype:
Before you begin prototyping, plan out which screens you’re going to include. I create a Word document, noting the screens, states, and interactions I plan to create. Then, as I create those things, I check them off the list.
Prioritize your list of screens and interactions so you’ll know where to spend your limited time.
When you receive change requests from clients or recommendations from usability testing, add them to your list as a way of keeping track of the changes you need to make.
Prototyping at the Wrong Fidelity
Most UX designers habitually use the same prototyping tool—often because it’s the tool their company provided or just because it’s what they’re familiar with. So they always create prototypes at the level of fidelity that the tool provides, without considering what fidelity is most appropriate for the situation.
There are two types of prototype fidelity:
visual fidelity—The degree to which a prototype represents the final visual design—from a black-and-white, wireframe prototype to visual-design mockups.
interactive fidelity—The degree to which a prototype simulates interactive elements—from a basic prototype that simply provides links between screens to a prototype that realistically simulates complex interactions.
The problem with always creating prototypes at the same level of fidelity is that might not always be appropriate for the circumstances. For example, instead of spending a lot of time creating a highly interactive, digital prototype, sometimes it’s better to create a paper prototype to get quick feedback on design concepts. Instead of designing highly polished visual-design mockups and using a simple prototyping tool to link the screens together, it may be more appropriate to create a wireframe prototype with some interactive elements, allowing you to focus on the taxonomy, navigation, labeling, layout, and interaction design.
To determine the best fidelity for your prototype:
Consider your purpose in creating a prototype. Is it to try out different design concepts? Do you intend to use these prototypes to get feedback on several design directions? Is it to test the usability of a design, show your client or project team how the design works, or show developers exactly what to create? Will your client use the prototype as a demo for their stakeholders? Or is it a combination of these purposes?
Consider how much time you have. In the ideal process, with all the time in the world, you would first create paper prototypes to quickly test the usability of one or more design options. Then, you would create a wireframe-based, interactive prototype and test that. Finally, you would create visual-design mockups, which you could link together to better show how the screens flow together.
When you don’t have time to create prototypes at all three of these levels of fidelity, a medium-fidelity, wireframe prototype is usually your best bet because it lets you test the most important elements of the design earlier in the design process.
Getting Carried Away by Creating Too Much
Using the latest prototyping tools, it’s so easy to create additional screens and simulate interactions that it’s easy to get carried away and try to show everything. You might think: Well, I might as well show how this works. I guess, since I showed that, I should also show what happens if you do this. Each piece of functionality that you prototype may take only a few minutes to create, but those begin to add up. Before you know it, you’ve built out a huge, complex prototype without your clients reviewing it or testing it with users.
By the time you do show it to your clients, their change requests may require you to to a lot of extra work. It’s especially difficult to make changes to a very complex prototype, with many screens, states, and interactions. Changes may break some of the interactions you created earlier. Sometimes it’s actually easier to start over with a new prototype than to make extensive changes to a complex prototype.
To prevent yourself from getting carried away and creating too much in a prototype:
As I mentioned earlier, plan which screens and interactions you’re going to show in the prototype. Prioritize which screens and functionality it’s most important to create first, then stick to that plan.
Begin at a high level, creating the basic screens first, without including too much functionality. Have your client review your basic designs, then make changes to incorporate their feedback, before getting into the next level of detail.
Schedule frequent design reviews so you can get feedback before going too far in a particular design direction.
If you have time to conduct two or more rounds of usability testing, test the basic design concept first, including the organization, navigation, layout, terminology, and basic features. During the next round of testing, focus on more of the interaction details and additional functionality.
Failure to Explain Types of Prototypes
UX designers may be so familiar with different types of prototypes that it’s easy to forget that clients, stakeholders, and participants don’t always understand what prototypes are. They don’t always recognize the difference between a prototype and a working user interface.
No one ever mistook a paper prototype for either a final design or a working user interface. Paper prototypes have the advantage of being obvious sketches of a design. They are crude representations of a design, and they require people to imagine how they would work.
At the wireframe level, prototypes begin to look more like a real user interface. When such prototypes are interactive, people sometimes mistake them for a final design. Despite a designer’s explaining that these are wireframes and the visual design will come later, you’ve probably heard people ask, “Why is it in black and white? It’s not going to look like this, is it?”
Because the latest prototyping tools can create very realistic interactions, people sometimes mistake prototypes for real, working applications. For example, during a recent design review, I showed stakeholders a search-results screen. Typing a term in the search field, then clicking the Go button, displayed the results. One of the stakeholders asked me to search for a different term. She thought it was a working search function, but it was really just two static screens with a Go button linking to a search-results screen.
During usability testing, participants sometimes assume they’re using a real application. When they click items that don’t do anything, they assume those items are broken. Unless the moderator explains why those things don’t work, this can give participants a negative opinion of the user interface.
To prevent such misunderstandings:
At the beginning of a project, explain the design process and its deliverables to stakeholders—including the difference between wireframes and the final, visual design. Explain this again at the beginning of each design review because people often forget this by the time another design review comes around. Plus, some of them may not have been in the earlier meetings.
Explain that interactive prototypes contain simulations of functionality.
Before usability testing, run through the prototype to ensure there aren’t any errors—such as links leading to the wrong screen—that would confuse participants or give them a negative impression of the design.
At the beginning of usability testing, explain to participants that they’ll be using a prototype in which not all of the links and functionality work, because they haven’t yet been created. When participants click something that isn’t an active element explain that it normally would work in the actual application, but you haven’t yet created that function.
Not Creating a Guide for Navigating the Prototype
Detailed, interactive prototypes can be difficult to navigate. By difficult I don’t mean the usability of the navigation. I’m referring to the ability to know what elements are clickable and the order in which people need to move around in the prototype to see all of the screens and interactions.
In a prototype, you’ll typically make only certain links, buttons, and controls active. It would be unnecessarily time consuming to make every element active. So, to get through the prototype, people must know the exact order in which to click elements to see all of the screens and functionality. There’s usually no visual indication of where to click. For example, even though all links may be underlined and look clickable, you may have made only some of them active.
Some prototyping tools have a feature you can turn on that highlights the clickable elements. That’s helpful, but it can also be distracting. Plus, it doesn’t indicate the order in which to click elements.
Not knowing where to click can be problematic when others try to review a design on their own. Even the person who created the prototype can sometimes forget the correct order in which to click through the elements when showing a complex prototype during a design review.
Create a guide that specifies the order in which to click elements in the prototype. I create a Word document, showing the items to click in blue text and other notes about the user interface in black text.
To prepare for a design review, run through the guide a few times, clicking through the prototype as you explain it. With that preparation, you’ll know what to do during the actual review, without having always to look down at the guide to know what to do next.
Provide a similar guide for clients and stakeholders to use as they review the prototype on their own.
Another option is to create a starting page, with links that lead to the different parts of the prototype you’ve implemented. Instead of providing just one link to the first screen of the prototype, this starting page can provide links to help people to get to each screen or function easily.
Some prototyping tools let you add annotations to screens, which you can use to indicate where to click. However, these can be distracting, so it’s best to be able to turn these annotations on or off.
For developers, in addition to the prototype, I provide an annotated wireframe document, showing each screen and state with text annotations describing the elements and interactions on that screen. This ensures that the developers can see every screen, so they’ll know how it’s supposed to work, rather than relying on their finding everything in the prototype.
The Best Advice
The best way to avoid making these prototyping mistakes is to design first, then prototype according to a plan. We’re fortunate to live in a time when there is an abundance of great prototyping tools that let us quickly create very realistic prototypes. However, with all this prototyping power, it’s very easy to get carried away by creating a prototype too soon, at the wrong fidelity, without proper planning, or with too much functionality. The result is a prototype that is too complicated and difficult to navigate. With the proper planning, you can focus your time and effort, create more effective prototypes, and avoid these mistakes.
Principal User Experience Architect at Infragistics
Cranbury, New Jersey, USA
Jim has spent most of the 21st Century researching and designing intuitive and satisfying user experiences. As a UX consultant, he has worked on Web sites, mobile apps, intranets, Web applications, software, and business applications for financial, pharmaceutical, medical, entertainment, retail, technology, and government clients. He has a Masters of Science degree in Human-Computer Interaction from DePaul University. Read More