I came across a Circuit Breaker Podcast episode called Understanding Prototyping to Learn. This episode is a MUST LISTEN! Bob Moesta and Greg Engle come from a hardware/manufacturing product development background but it all applies to prototyping on the web. Bob and Greg give some much needed language to the discipline of prototyping.

The roles of prototypes

Did you know your prototypes can serve different purposes? Bob and Greg have big buckets for them.

  • Learning prototype
  • Communication prototype
  • Milestone prototype

These are wonderful categorizations of the roles prototypes can play. I often prototype to learn. My CodePen is full of these. I often prototype to communicate: “Here’s some progress, here’s why something can or can’t work”. It lets everyone see and experience the same tangible artifact. I prefer prototypes over talking abstractly in meetings. As the old IDEO saying goes:

“A prototype is worth a thousand meetings.”

The “milestone prototype” concept, where you put a new prototype next to the old prototype to show progress, was a new distinction to me. I’ve used prototypes to communicate progress, but not to show progress. I love it! Show, don’t tell. Simple, yet so effective. Having the v0 next to the v1 tells a story. This could be difficult in code prototypes where you often stomp over previous work, but this might be a situation where a regular habit of branch deploys or CodePen forking goes a long way.

The types of prototypes

Bob and Greg also explore the different types of prototypes and how they can be decision facilitators:

  • Divergent - Exploring different directions
  • Convergent - Exploring tradeoffs

As they said in the podcast, divergent prototypes “are about helping people eliminate what they don’t want and helping us build the criteria of what they want.” Divergent prototypes create contrast.

“This is where you can compare an apple to an orange.”

Convergent is about optimizing or managing the tradeoffs. The example they use is “Light” vs. “Strong”; you can make an object light but light materials typically aren’t strong, unless you want to add cost. You’re figuring out what levers you can change to meet a customer’s need and converging between specific options.

A way to sum this up might be if the customer problem is “Getting from point A to point B”, a divergent prototype would be to show them an airplane, a submarine, or a car. A convergent prototype would be showing a customer a Prius, an SUV, or a pickup truck where you compare size and utility against range (miles per gallon).

It reminds me of Ken Kocienda’s story of the iPhone keyboard. There were a lot of divergent prototypes (created in Shockwave, ironically) that passed by Steve Jobs’ desk. Once Steve blessed a path, Ken’s team flipped into making convergent prototypes. But because investements were shallow, they weren’t afraid of rework and backtracking if necessary. In Ken’s words:

Demos were the catalyst for creative decisions, and we found that the sooner we started making creative decisions—whether we should have big keys with easy-to-tap targets or small keys coupled with software assistance—the more time there was to refine and improve those decisions, to backtrack if needed, to forge ahead if possible.

The dimensions of prototypes

Prototypes aren’t uniform in scope and sometimes look at problems from different scopes or dimensions:

  • Comprehensive prototype - Explore how many aspects fit together
  • Focused prototype - Focus and optimize a single aspect

A customer might need a more comprehensive prototype to see how all the pieces (or multiple prototypes) fit together; the 10,000 foot view. Or a prototype can zoom in on a specific feature or component. Each dimension asks radically different sets of questions, which Bob and Greg also cover.

Questions you should ask from your prototype

A good prototype helps answer a question. The questions Bob and Greg came up with were:

  • “What question are you trying to answer?”
  • “Why are you doing it?”
  • “Who is it for?”
  • “What do you hope to learn from it?”

If I were going to riff on this, I’d boil it all down to: “What’s the one thing you need to know?” I think most of the other questions hang from that question. The episode ends in a hurry with one final question…

Is A/B Testing prototyping?

At the end of the show, they ask a question I sometimes ask myself: “Is A/B Testing a form of prototyping?” Their answer:

In the world I grew up in, A/B Testing was known as the worst way in which to test prototyping.

🌶 So spicy. I have lots of thoughts on A/B Testing but I generally regard it as a tool in the tool belt. I agree with nuance that one of the major problems with A/B testing is “it falls apart because you don’t know why that thing works.” You can’t let “numbers went up, ship it” guide the process. You need to know why. You need both sides of the coin, the quantitative (A/B testing) and the qualitative (user testing), side-by-side informing each other.

Adding my own nuance, I’d argue that A/B Testing —at least in digital realms— can be a great way to quickly validate a prototype or idea outside of a lab setting with real customers. It can —if done well— eliminate some subjectivity around design or temper “big ideas” from executives. My favorite A/B tests are actually the tests that fail, because you find out early if an idea is a bad idea. But your organization needs someone who can read the tea leaves and document why it failed.

Ken Kocienda again:

A/B tests might be useful in finding a color that will get people to click a link more often, but it can’t produce a product that feels like a pleasing and integrated whole.

Sounds like a good place for a comprehensive prototype.

So much to learn from prototyping

Prototypes teach you a lot about your product. Where it’s going, where it’s been, what can we change, what’s hard to change, what problems might arise, and —most importantly— will customers like it when we get there?

I love prototypes and talk about them a lot but I garnered so much from this episode. These insights from another industry give a lot of language, structure, and purpose to prototyping. A good prototype creates contrast that can speed up decision making. I think I’ve always focused on the “fun” or anarchistic problem-solving outside of the big corporate machine aspects of prototyping, but Bob and Greg put prototyping in a button-up shirt, ready to do business by solving customer problems.