What To Do With an Idea: Build It, Break It, Fix It

The three steps of productive prototyping

So you’ve got an exciting idea. You can’t wait to put it into action. Maybe, to arrive at your idea, you did some real needfinding work by engaging with some real users. Either way, you’ve got a concept for a solution you believe will be transformative. Now, all you have to do is prototype and test it, right? Right!

But…what do those words really mean? What do they really look like in practice?

“Prototyping” and “testing” might feel like abstract concepts. Indeed, their abstractness might even feel intimidating. In order to ground them in a more actionably simple framework, I offer the following. To move an idea forward, do just three things: build it, break it, and fix it.

1) Build it

Do whatever it takes to bring your idea to life. Draw something visual. Make something physical. Create an audio or video experience. Build something that your user can experience or that you can try out functionally. Move away from having to explain your idea verbally and toward being able to demonstrate your prototype experientially. You want to be able to show, not tell.

Why isn’t it sufficient to simply describe your idea to someone? Because verbal descriptions only tell a partial story. If I were to describe an idea to you with words, there’s no guarantee that what you’re picturing and what I’m picturing are the same. Thus, any feedback you give me will only be as valuable as our mental models are similar.

Moreover, it’s easy to gloss over details when sharing an idea with words. Making the idea tangible requires you to fill in the gaps. As Edward de Bono explains in Lateral Thinking, “The advantage of a drawing is that there is far more commitment than with a verbal explanation. Words can be very general but a line has to be put in a definite place.” This concreteness provides a quantum leap of both quality and value of feedback.

You may be inclined to respond, “That sounds really interesting, but my idea doesn’t really need to be built; my idea really needs to just be described.” Don’t fall into that exception trap. Don’t let the attractive misconception that your idea is ‘different’ keep you from moving forward. I’ve never met an idea that was truly an exception. Just build it. And then…

2) Break it

Once you’ve built something, do everything you can to break it. Fast. Put it out in the world or in front of a user and let it break. Rather, make it break.

Too many teams I’ve worked with stop once they’ve built a prototype. They sit back and relish in their achievement or simply assume that the act of building is the key source of value. We’ve all done it. Investing even a small amount of time and energy into building a prototype leaves us, well, invested in it. Prototypes can feel sacred. They’re not. That’s the point. Your prototype is a means, not an end. It’s a journey, not a destination.

To break a prototype, fundamentally, is to identify its literal and/or figurative weak points. If you have a functional physical prototype, you may actually be breaking it. If you have a sketch, a storyboard, a wireframe, a video, or a non-functional physical prototype, you may simply be uncovering discontinuities in the workflow, features that don’t quite deliver or articulate the intended value, or other aspects that don’t make sense yet. In any case, the goal at this stage is to focus more on what doesn’t work well than on what does.

In breaking your prototype, you’re testing the what (the prototype itself, this specific manifestation of your idea), the how (how your prototype interacts with the world or the relationship between it and your user), and the why (why it exists in the first place, the idea and the needs it’s meant to address). Indeed, you’re not just trying to break the prototype — you’re also using the prototype as a means to break the idea. “Breaking” the idea, similarly, is about finding where it doesn’t quite address the intended need or carry out the intended function.

Discovering the places where your prototype breaks is the most critical step of the three. Don’t stop once you’ve simply built it. And once you’ve broken it, don’t be afraid to face, to borrow Jim Collins’ term from Good to Great, the “brutal facts.” It can be tempting to ignore the things that don’t work, hoping they’ll magically disappear. They won’t. You’ve identified the breaks; now you need to address them. So now…

3) Fix it

“Some of our greatest learning comes from a failed prototype, because then we know what to build differently next time,” say Bill Burnett & Dave Evans in Designing Your Life. Now that you’ve built something and broken it, it’s time to build it differently next time; in other words, it’s time to fix it.

The first step in fixing it is to identify what broke. Grab your “broken” prototype and list out everything that broke as well as everything that “bent.” If you have any ideas for how to make your prototype better already, note those as well. Great, now we’ve got a list of the “what.”

Now, it’s time to ask: “Why?” Why did your prototype break where, how, and when it did? Did a feature fail due to design or due to implementation? Was a feature so good that it got overused, which led it to break? Was there a feature that users loved so much they got distracted by it? Was there a discontinuity of workflow that lacked sufficient guidance? Was there an issue with the prototype itself, or does the problem seem to be more fundamental to the idea? Understanding the possible root cause of each break will let you build it better next time.

Finally, prioritize which broken parts to fix first. You may choose ones that are quick and easy to fix so you can start learning again as quickly as possible. Or you may choose ones that are a bit more involved but that could have a greater influence on the success of the prototype. Either way, once you’ve prioritized, fix your prototype.

Then, go break it again.

Learn more about my approach to design & innovation at www.lightshed.co.