The prototype is the pitch.

We used to do something like this in the Flash era. The difference is that it required rare, highly specialized people to pull off. Now it requires designers with the willingness to work a new way.

What happens in the room.

The effect on the client presentation is hard to overstate, but I’ll try to be precise rather than reach for superlatives.

When clients see a fully interactive prototype at the vision/discovery stage, the conversation changes register. It stops being about whether they can picture the direction and starts being about whether they want to evolve it. The imaginative work has already been done—by the prototype, not by them. That’s a different kind of trust, and it produces a different quality of feedback. Specific, confident and forward-looking rather than hedged.

On a recent project, a client who would ordinarily have required multiple rounds of alignment approved the direction in the first presentation. And this was the result of a crystal-clear tactic: making sure there was nothing left to interpret.

But the bigger change isn’t as much getting approval as it is where the project goes from there. Because the prototype is truly the foundation the project builds from, not just a flashy pitch artifact. The flows are real. The interactions are real. What would previously have been a discovery phase followed by a build phase becomes, effectively, a running start. And clients are further along the process than they used to be at this point. That compresses the overall timeline in ways that have real cost implications, and it means the first design sprint begins with something to react to rather than something to imagine.

That’s a different conversation to be in, and a different kind of project to run.

The second phase is where it compounds.

After vision alignment, we move into design sprints. This is where Figma and Claude work together to change something structural about how the work accumulates.

In the traditional model, the design system is a parallel workstream. Someone maintains it, someone contributes to it, and there’s a constant tension between moving fast on features and keeping the system coherent. Documentation lags. Handoff files diverge from what actually gets built.

What we’ve found is that if you build components into the design system as you design them—resolving states, variants, tokens, interactions feature by feature rather than in a separate phase—the system emerges from the work rather than running alongside it. By the time a feature is designed, its components are already systemized. Development receives something they can build directly from, rather than interpret and approximate.

It doesn’t eliminate the handoff. It just makes the handoff much less of a translation exercise.

What this is actually about.

The previous article I wrote for this site was about mindset—the restless, generalist energy that produced interesting work in the nineties, and why AI is creating conditions where that energy is relevant again.

This is the practical version of the same argument. The reason designers lost proximity to the making wasn’t a failure of ambition. It was structural. The stack demanded separation. The tools enforced it. The roles calcified around what each discipline could reasonably own.

That structure is loosening. Not because the technical complexity has gone away, but because AI is absorbing enough of it to let designers get back close to the material. The Flash specialists took years to develop their craft. Claude Code is available now, to anyone willing to work differently.

The middle ground is back. What you do with it is still up to you.