Prototypes as
Decisions

The prototype is the artifact

Figma is a great space for making pictures of a product. It is not a great space for making the product itself. The moment a design has to answer does this actually work — for a user in a testing session, for a stakeholder deciding whether to fund it, for an engineer estimating scope — a Figma frame stops earning its weight.

So I moved my prototyping into Claude Code. Every serious concept I work on gets built as a real React app: real routing, real state, real microinteractions, real responsiveness. The prototype behaves the way the product would. That behavioural fidelity changes what the artifact is used for.

What that unlocks:

• Moderated user sessions run on the real thing. Suppliers don’t tap through screens — they complete tasks. Friction that only appears when the UI actually responds surfaces where I can see it, not weeks later in an engineering ticket.
• Stakeholder review shifts from opinion to walkthrough. Executives don’t debate whether a mechanic could work. They open a link, run the flow, and see the failure modes with me in the room.
• The fifty small questions get answered up front. Modal behaviour, empty states, loading states, keyboard focus, motion timing — the prototype resolves them before engineering has to ask. How that translates into a formal engineering handover is a workflow question we’re actively working out (see section 03).
• My own thinking gets tighter. Code refuses to accept the vagueness Figma accepts. If I don’t know how a state resolves, I can’t render it. That forcing function catches design decisions I would otherwise have deferred.

The loop I actually run

Claude Code is not a tool I use to type faster. It is a collaborator I brief carefully. The quality of the prototype is a direct function of the quality of the brief — the same way the quality of a hand-off is a direct function of the spec that came before it. I run a repeatable four-stage loop.

The loop stays small. A phase is scoped so I can walk it end-to-end in under ten minutes. When something drifts — a modal that doesn’t quite land, a microinteraction that reads wrong — I don’t argue with the code, I edit the spec and re-run the loop.

The rules I hold Claude Code to

The workflow only works because the constraints are explicit. In every project’s CLAUDE.md I write the same handful of rules:

• Modular, not monolithic. Every distinct UI region — modal, sidebar, card — lives in its own file. Bugs stay isolated; regressions stay small.
• Mock data in one place. A single mockData.js — no seed values scattered across components. When I need to swap archetypes for a walkthrough, it’s one file.
• Never invent data. If a number, name, or piece of copy is missing, Claude Code has to ask. Plausible-sounding fabrication is what makes AI-native prototypes untrustworthy — banning it is the first line in every brief.
• Focus on the feel. Hover states, transitions, shadow depth, typography hierarchy, empty states. These are the details that decide whether a stakeholder believes the concept.
• No boilerplate tax. No tests, no strict TypeScript. This is a prototype, not production — the discipline is design discipline, not engineering discipline.

How I collaborate, iterate, publish

A working prototype is only useful if the right people can reach it. Every prototype I build lives in an Azure DevOps repository and moves through the same git-driven loop the engineering teams use.

• Branch per concept. Different candidate paths — different acquisition mechanics, different upgrade flows, different questionnaire structures — get their own branch. When leadership asks "what does the other path look like," it’s one checkout away.
• Commit as decision log. Each commit is a small, named design decision. Reading back through the history is reading back through the design reasoning — which round of testing killed which idea, when a stakeholder note reshaped a flow.
• Deploy pipeline for stakeholder review. Azure pipelines build the prototype and push it to an App Service URL. Executive walkthroughs happen on a live link, not a laptop.

The open question: handover

Once a prototype has done its job — hypothesis pressure-tested, direction chosen — the next question is how does this get to engineering, cleanly, with quality gates satisfied. That’s not settled yet.

The traditional route — Figma frames, red-lines, spec docs written after the fact — throws away most of the fidelity the prototype already carries. So we’re running an experiment: can the prototype itself be the handover artifact? The commit history is intentional, the components are structured, the tokens come from the design system. In principle, the prototype has more decisions captured in it than any spec doc I’d write on top of it.

Whether it clears the bar for engineering to actually build from — code quality, testability, accessibility, performance, the invariants a production codebase requires — is what we’re actively finding out. Some pieces will transfer directly. Some will need to be rewritten to production standards. The value the prototype delivers into that handover is intent, resolved — the fifty small design decisions engineering would otherwise have to ask about are already visible in a running, clickable thing.

That experiment is where the practice is heading. What I can commit to is that the prototype makes the design decisions unambiguous. What form of handover that becomes is a question we’re answering in the open.

The shift, in one line

Discovery used to end with a deck. It now ends with a link. The deck said here is what we think; the link says here is what we tested, here is what broke, here is what to pilot. Same team, same timeline — different depth of evidence going into the go/no-go conversation.

The reason I lead with this way of working is not that Claude Code makes design faster. It’s that it makes design testable earlier. The design decisions that would have surfaced expensively — in a pilot, in a regression, in a support ticket — surface cheaply, in a walkthrough, before any code is committed to the roadmap.