CALM: Prototype to Learn, Not to Impress

Sometimes, the calmest way to move a project forward is to make the idea testable before anyone invests too much in defending it.

A prototype is not a presentation artifact. It is a risk-reduction tool: a way to make one critical question tangible early, while misunderstanding is still cheap and before building effort turns every change into rework, re-checking, and sunk-cost resistance.

So we build the smallest believable thing — a sketch, model, sound cue, interaction mockup, or mixed prototype — that can answer one important question and leave the rest unfinished on purpose.

Before one of my first design projects, I noticed that teams moved almost directly from specification to implementation. New concepts were only shown as implemented solutions, usually late in the project, when engineering effort was already high and changes felt expensive. Feedback at that stage was hard to welcome, not because people were unwilling to listen, but because so much effort had already been spent that every critique sounded like reversal.

I started introducing rapid prototypes to make concepts tangible and interactive much earlier, while the design was still open. After several thoughtful internal conversations and some critical questions, we brought that approach to a conference and invited around 40 participants into a hands-on feedback session. We used interactive user interface (UI) prototypes on phones embedded in 3D-printed models, and the response was a breakthrough: people showed us where expectations broke, where interaction felt awkward, and where our assumptions had outrun real use.

Before, concepts arrived as finished artifacts. After this, they arrived as questions people could challenge while change was still cheap.

The same pattern shows up across product teams everywhere: in software, hardware, device interaction, sound design, and service workflows, discussion gets clearer when concepts are tested before implementation hardens them.

One thing to remember: Questions that stay abstract do not disappear in implementation. They usually return later as extra steps, rework, hidden checks, and longer discussions under more pressure.

How teams ship this: Before building, write one sentence: This prototype exists to learn whether... Then keep the prototype just believable enough to answer that question and no more.

Prototype Question Card
Use these five points before building anything:

This keeps the team focused on what must be learned now, instead of quietly expanding the prototype into premature design debt.

Sketching User Experiences by Bill Buxton.
It remains one of the clearest reminders that early artifacts should help teams explore, compare, and learn before they commit too much too early.

Which question in your current work is still being discussed abstractly because nobody has made it concrete enough to test?

Notice one idea you are currently explaining more than you are testing.

Today, notice where a simple prototype could create more honesty with less effort.

Best,
Andreas Walden

Share this with someone designing for clarity.

Artificial intelligence speeds up prototyping, but it does not change the reason for prototyping. The risk is that teams now generate polished screens, physical interactions, voice moments, sounds, flows, and live demos so quickly that they forget to name the question those artifacts are supposed to answer. IDEO frames this well: speed alone is not the goal; the goal is meaningful feedback and better decisions. NN/g makes the complementary warning that artificial intelligence prototyping tools can follow broad directions while still missing the judgment and nuance of an experienced designer.

So the calm rule becomes stricter, not looser: use artificial intelligence to widen exploration, lower setup cost, and surface alternate directions, but never let it hide the learning objective. Ask it for contrasting flows, physical states, audible cues, error recovery paths, handoffs, and different levels of fidelity. Use it to make questions visible faster, not to make weak ideas look finished.

A simple team practice helps: every artificial intelligence-generated prototype should carry a label with three lines — what question it is testing, what is fake, and what decision it can or cannot support. That keeps the prototype honest, protects engineers from premature commitment, and keeps the team focused on learning rather than spectacle.