Five Prevalent Pitfalls When Prototyping

Nathan Curtis, one of the geniuses at the design firm EightShapes, likes to say “Don’t tell me, Show me.” When talking about a design, Nathan wants to see (and possibly play with) a prototype to better understand what’s being proposed.

Nathan’s not the only one. Prototypes are a fabulous way to explore ideas with a team. They shorten the time between “This is what we’re thinking…” and “Oh, I get it.”

In our work with design teams, we see a lot of teams using prototypes today. We’re also seeing many of those same teams fall into traps that reduce the effectiveness of their prototyping efforts. Here’s five of the most common ones we see.

Pitfall #1: Focus on the Deliverable, Not on the Learning

A great prototype can sell an idea better than a specification or other form of describing the design. Seeing the design in action and playing with it brings the underlying ideas to life.

It’s no wonder that we focus so much on what the prototype will look like and how it will work. We want to achieve that wow factor with the key decision makers and stakeholders on the project.

As important as the working prototype is, it’s not the most important outcome of a prototyping effort. What’s more imporant is what the team learns from the prototyping process.

You can learn a lot in a variety of different areas when building out a prototype:

Learning about the problem

• What do we now know about what we’re trying to design for?
• How did building the prototype change our perceptions of how to solve the problem?
• What parts of the problem are easily solved?
• What parts of the problem remain big challenges?

Learning about our users

• What new things do we now understand about our users?
• What new questions do we have about them?
• What will be easy for users to do with our design?
• What might still be messy for them to accomplish?

Learning about the materials

• What will be easy to implement?
• What will be a challenge to pull off well?
• What new skills do we have to master to get the best design?

Learning about potential solutions

• What design alternatives are there?
• Which of those alternatives provide the best outcomes?
• Why do the less appealing outcomes fail the design?
• What elements might be useful design patterns going forward?

We love seeing teams present both the prototypes and what they learned. Some teams create an open diary of the prototype project, talking about what they’ve learned as they’ve learned it. By pushing the focus on what they are learning, they make everyone around them smarter about what they’re trying to accomplish with the final design.

Pitfall #2: Too Much Converging; Not Enough Diverging

It’s tempting to fall in love at first sight with an idea that’s a huge improvement over anything you’ve done before. We see teams do this all the time. Once they’re in love, they declare “That’s the one!” and start perfecting and refining the idea.

Selecting and idea and refining it is the convergence part of the prototyping process. Skilled teams know to hold off on that, staying in the divergence part of the prototyping process much longer.

When diverging, the team doesn’t settle on a single design idea. Instead, they ask how else they could solve problem, trying as many ideas as they can. What if we did it this way? What if we used this other approach? These questions help bring up alternatives that might not have been considered before.

By spending more time diverging, the team learns more about the problem space and the potential solutions. When they compare one approach to another, they learn the dimensions and quality of what could make a good design. Asking which alternative is better brings out discussion about the nuance of the problem and the potential solutions that wouldn’t happen if they didn’t have the comparison point.

Of course, trying out lots of alternatives means having prototyping tools and techniques that are fast and flexible, which is where our next pitfall comes in.

Pitfall #3: Working in the Wrong Fidelity

Prototypes come in all shapes and sizes, from whiteboard or napkin sketches all the way up to can’t-tell-if-it’s-real uber realistic running software. You can use a pen and paper, a simple drawing tool like Omnigraffle (though Omnigraffle is always much harder for me than I think it should be), or design-in-the-browser jQuery, CSS, and HTML.

It’s tempting to jump quickly to something that will look like the final design. This would have the right looking icons and typography. It would have highly-stylized layouts and sophisticated color palettes. (Who doesn’t want sophisticated color palettes?)

A great designer, however, chooses the right fidelity for where they’re at with the design. Lower fidelity, like a pen-and-paper sketch, produces a different kind of reaction and critique than higher fidelity, like a jQuery rendition. (This is why tools like Balsamiq try hard to fake a lower fidelity.)

Low fidelity prototypes are faster and easier to create. They are perfect for the divergence part of the project. Sketching out 20 variations and posting them side-by-side on the wall gives the team a nice perspective on what the possibilities are. “Oooh. What if we combined this thing here with that thing there?”

High fidelity prototypes are slower to create, but yield more subtlety and nuance. They give off the feel and are easier to compare to the details of the scenarios. “What happens when our user runs into that special circumstance? How does the design handle that case?”

Choosing the right fidelity for the project’s current needs is essential to the success of the project and the value of the prototype.

Pitfall #4: Too Little Evaluating

You can break a prototype iteration into four distinct stages:

Planning—What do we want to learn from this round of prototypes? How will we tell if we’re getting closer to a final design?

Implementing—Building the prototype or prototypes.

Measuring—Collecting data, such as opinions or usage information, to tell us how well the prototype performed.

Learning—Look back at the iteration and discover what we now know that we didn’t know before, and what questions we now want to answer in the next iteration.

Those last two stages—measuring and learning—are how we evaluate the prototype we’ve built. Many teams create prototypes without ever evaluating them, or even thinking that they should.

When you skip the evaluation stages, you can’t tell what you’ve learned from the prototype effort. Evaluation doesn’t have to be difficult. It can be a simple critique, asking, “does this do what we were trying to do?” Or it can consist of a scenario walkthrough or a simple usability test.

The best teams know how they’ll evaluate the prototype before they build it. This helps them pick the right fidelity for the iteration, getting them quickly to the best results.

Pitfall #5: Fixating On A Single Prototyping Tool

Some prototyping tools, like Axure or iRise, have a lot of promise. However, they also take time to master. Even becoming proficient at sketching or using jQuery takes time and effort.

Because of the effort, some teams want to find one tool and use it for everything. Their thinking, they tell us, is that they need to recoup that learning investment, so they plan to use it for everything.

However, the best teams don’t limit themselves to just one prototyping tool. They’re constantly sharpening their skills on different tools. (Pro trip: hold regular “prototypathons” where small teams compete with tools they’re uncomfortable with.) They look at every type of fidelity, so they’re prepared to meet any challenge.

Proficiency in any tool comes with practice. Spreading out that proficiency with a bunch of tools delivers flexibility. It all comes down to rehearsing and variation.

Getting the Most from Prototyping

Prototyping, on the surface, looks like making something that works. But that’s a narrow view.

Prototyping is rendering ideas to understand them better. It’s a way for the team to dive deep into the process of design and their understanding of the problem to solve. It’s an effective way to show progress throughout the project cycle, not only by having something substantive to display, but by creating a vehicle to talk about the decisions the team is working through.

Avoiding these common pitfalls helps teams get more from their prototyping process. In turn, that produces better designs.