Originally published: May 02, 2013
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.
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
Learning about our users
Learning about the materials
Learning about potential solutions
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.
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.
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.
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.
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.
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.
While you consider the prototypes your team creates, and how to avoid these pitfalls, you’ll want to be sure you have the right fidelity for the research you’re conducting. Next week, Carolyn Snyder returns to the virtual seminar program to present Prototypes: Choosing the “Right” Fidelity for Your Research. Carolyn will show you which project variables to consider when choosing what to test in the first place, and then how to create an effective prototype that minimizes work and maximizes learning. Learn more about Carolyn’s seminar here.
Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems.
Have you run into any prototyping pitfalls? Let us know on our blog.
Read related articles: