Six weeks into the design of a developer tool, our team had three competing models for live preview and no shared way to judge them. We spent two weeks talking in circles. Each proposal looked plausible in a static design, and each person could project a different implementation onto the same frames.

I built the interaction over a weekend in HTML, CSS, and JavaScript. The following review took about 45 minutes. We could feel the latency, see how state moved through the interface, and discuss engineering cost against something concrete. The prototype did not win the argument for me. It gave the team a better argument.

The fidelity should match the uncertainty

Teams often talk about prototypes as if fidelity were a ladder: sketch, wireframe, polished design, code. That framing misses the more useful question. What kind of uncertainty are we trying to remove?

If the uncertainty is about comprehension, a sketch may be enough. If it is about information hierarchy, a static design might be right. But when the disagreement concerns timing, feedback, state, data structure, or technical constraints, another static artifact adds polish without adding evidence.

The prototype should be only as real as the question requires—and real in the dimensions that matter.

Our live-preview debate was not fundamentally visual. It was about how much delay users would tolerate, when the system should commit changes, and what engineering would need to keep synchronized. Code made those hidden variables visible.

A prototype can be a boundary object

The best prototypes are not private design artifacts. They become boundary objects: something product, design, and engineering can each inspect from their own angle without needing to agree on every abstraction first.

For our builder work, the underlying schema was JSON and difficult even for technical users. Building against that structure forced me to understand the system rather than design around an imagined version of it. Engineering could point to implementation tradeoffs. Product could test scope. Users could react to behavior. Design could evaluate the full experience.

One artifact carried several conversations that previously happened in isolation.

Decision velocity is the output

A coded prototype is not automatically better. It can become expensive theater: too polished to challenge, too brittle to learn from, or too far ahead of the team’s actual decisions. The goal is not to prove that a designer can code.

The useful output is decision velocity. Before building, I look for four signals:

  • The team is repeating the same abstract debate.
  • The risk lives in behavior rather than visual presentation.
  • A working model can expose a constraint within days, not weeks.
  • The people making the decision will use the artifact together.

If those conditions are not present, code is probably unnecessary. If they are, the prototype can compress weeks of interpretation into one shared experience.

Code is not the deliverable

The prototype I built was not production software, and treating it that way would have undermined its value. Its job was to reveal the system, test the interaction, and align the team. Once it had done that, engineering could build the durable version with a much clearer target.

Design engineering is most valuable to me in that space between an idea and a commitment. Code becomes a way to reason in public—to make a claim tangible enough that other people can improve it.