Product designers know that building prototypes is a useful way to test a product idea. But how polished should the prototype be? Can you use paper for the design, or do you need a fully functioning app? Put another way, how low fidelity or high fidelity should your prototype be?

These are tough questions to answer. Once an idea starts coming to life, it’s tempting to put too much weight on high-fidelity prototypes as if they were fully baked products. So how can we know what fidelity we should be operating at?

Low-Fidelity Prototypes

Prototypes are ultimately vehicles for feedback. In the world of design, there is a wide spectrum of inquiry where all things can act as vehicles for getting feedback and learnings. On one side of that spectrum you have really low fidelity, and more abstract representations. And on the other side of the spectrum, you have high fidelity, or really concrete executions of ideas.

On the low-fidelity side of the spectrum you are really exploring the questions of “What should we build?” On the low-fidelity side, I would include formats like paper wireframes or even card sorting exercises with a deck of cards where each card represents a potential feature for a dashboard. These cards can be used for sorting exercises with potential customers to understand prioritization, desirability of features, and the “why” behind a person’s responses.

High-Fidelity Prototypes

On the high-fidelity side of the spectrum, you are really exploring “How should we build it?” Here you might find proofs of concept or even iterative versions of a concept applicable. These are actual fully functioning executions of a concept, but they can still be used to get feedback for future versions. An example of a high-fidelity prototype would be the 2014 Jeep Cherokee versus the 2017 Jeep Cherokee. When Jeep introduce the 2014 Cherokee it got plenty of unsolicited feedback from an array of automotive critics who thought the front fascia was a hot mess. Now I’ve never seen anything to suggest that Chrysler admitted the error of their ways, but when the vehicle was refreshed for 2017 there was a more traditional design up front. Whether or not Chrysler admits it, their product yielded feedback that influenced the next iteration of “how” they were going to make their product.

When You Should Go Low Fidelity

The less confident you are in knowing the wants and needs of the customers, the more you should be operating on the low-fidelity side of the spectrum. At Moonshot, we are currently working on a project exploring the deployment of augmented reality as a wayfinding tool in a convenience store environment. For the purposes of research, our team is building a prototype for us to learn about how people might react to such a concept and what they might expect from it. We have had interesting conversations about how this prototype should be brought to life. Part of that conversation has been whether we need to include more functionality now to better represent how the concept might work in the future. Including more functionality now would shift our prototype further to the higher-fidelity end of the spectrum. Doing so would require more hours of development without ever having tested the overall concept with users. To remind the team where we are in the process I introduced a donut analogy.

The Donut Analogy

I asked one of my colleagues to imagine that I wanted to test a new donut. I told him I was going to share this new donut with him and that when I did so, I wanted him to share his honest feedback with me. I then offered my colleague a donut but handed him a pencil. There was a bit of an “aha” moment here with the team because they understood that while a pencil is certainly not a donut, it is nevertheless a tool that can be used to learn about what my colleague was expecting to see. I could still ask questions about what his usual experience is with a donut; what the last donut he ate was; how this pencil was not like one of those donuts he had before; and what would need to change with the pencil in order for it to be more like what he was expecting. Similarly, we didn’t need to add functionality to what we had already created to have a meaningful conversation about how someone might expect a navigational tool to function in a convenience store environment.

But why should you start with low fidelity first, and how can we communicate an idea if we haven’t made the functioning product yet? This is the beauty of design research where you creatively solve for bringing to life representations of ideas without needed a fully functioning product.

The Power of a Box

Let’s say I wanted to get feedback on a concept like Tide’s Pressbox laundry service, which allows people to drop off their clothes in a designated locker for cleaning. Right now, users can download the Pressbox app to notify the service that they have dropped off their clothes, provide instructions about cleaning, receive notifications for when their laundry is ready, and locate a code to unlock the locker to retrieve their clean clothes. To bring this service to life you would probably need a partnership with a laundry facility or you would need to acquire new facilities. You would need to secure lockers and find an appropriate space to place them, and you would need to develop an app and get it into the app store. That app would need to have at least different views for the users and the launderers who do the cleaning.

But how do we get feedback on such a complex service without bringing it to life? To do these things, all you would really need is a box. That’s it!

I have seen so many prototypes come to life simply by repurposing a box. In this instance, the box has become a boundary object that allows you to have a conversation about how people might expect this service to work. You don’t need an app to learn how often someone might use this service. You don’t need a laundry service partner to learn about what would be needed for people to feel comfortable to use this service for all of their clothing. You don’t need a locker to learn about the ideal location for this service. All you need is a box.

The Outcome of a Prototype

A prototype is something for people to react to. The outcome of working with prototypes is not the idea you are testing, but rather the learning you gain from the interaction. It is what people say and feel about your prototype. So when groups embark on missions of exploring concepts and their potential, it’s easy to begin with the best of intentions of residing on the low-fidelity side of the prototyping spectrum and trying to explore what to build, but it’s so easy to find yourself slipping to the right as prototypes come to life — and then spending too much time perfecting how to build it. Excitement builds, ideas become precious, and next thing you know, you have built what you think is the answer when you were supposed to be building the question. The prototype has now shifted from being a vehicle for learning to being a precious product.

Do we know what people want? The more confidence you have, the more empathy you have for your user, and the more confident you can be in moving to the right of the spectrum. The beauty of prototyping is that everything can be a prototype. Everything can be used to learn more about what people want, and need, and why that might be true. Once you recognize where you are, you can make better decisions about the level of fidelity you are using to bring concepts to life.

Just don’t be afraid to start low and stay low and then move up from there gradually. For more insight into product design, contact Moonshot.

Ben Hillson

Ben Hillson

Experience Strategist

Bitnami