How we put Claude into our design process and got a clickable prototype 3x faster

Before anything is drawn, the people who will build the feature meet for a short working session: product, design, front-end and QA. The result is a one-page brief.

We did not invent this. It is the Three Amigos workshop that teams doing behaviour-driven development have used for years: one person to request, one to suggest, one to protest, usually product, a developer and a tester, kept to 30 or 45 minutes. If it runs long, the feature is too big. The tester asks about partial failure while the answer is still free. The front-end lead says "that component doesn’t exist" before anyone draws it.

With AI, the brief became more than a record. It is now also the input. Engineers arrived at the same idea on their own and call it spec-driven development. GitHub’s Spec Kit turns it into three steps, specify, plan and tasks, on the argument that "code is really not the best medium for requirements negotiation." Addy Osmani’s guide to writing specs for AI agents says much the same from the practitioner side: write it like a product requirements document, state the boundaries clearly, and keep it versioned.

Our one addition is small. We put a closed list of components in the brief. It stops generated screens from quietly forking a design system that already spent a decade fragmenting on its own. If something is missing, that becomes a question for a person, never an invented colour value.

Claude does not make up interfaces from imagination. It reads the client’s published component library through the Figma connection, builds screens from components that already exist, and writes the result into the two places the team already works in.

The connection is called MCP, a standard way for an AI to work directly inside other tools. Figma’s version comes in two flavours, a local one through the desktop app and a remote one at mcp.figma.com/mcp, and in supported apps it can now write to the canvas instead of only reading from it (Figma’s guide, the remote-MCP announcement). On the other side, the GitHub connection handles the branch, the commit and the pull request.

None of this is exotic. Connecting the tools took an afternoon; it is configuration, not engineering. The real cost came earlier: six weeks of cleaning up the design system so there was something worth generating from.

A single run produces frames on the Figma canvas and a working prototype on a link, both from the same components, so they cannot drift apart.

The frames arrive as real library components, so a designer can edit, rename and re-theme them like any other file. The prototype arrives as a branch with a live preview, so anyone in the company can open it, select rows, trigger the failure case and comment on the thing itself instead of on a picture of it.

That changed our review culture more than we expected. On an old platform, the people who know why a rule exists are rarely in the design review. Give them a link and they click it, and the objection arrives in two days instead of two sprints.

The front end is no longer rebuilt from a static picture. It is taken, kept and wired up. The backend, logins, real data, performance at volume and tests are exactly as much work as before, and we do not claim otherwise. A designer working this way independently describes the same split: a "shadow repo" that mirrors production patterns, Figma MCP for visual direction, and developers who finished the production version "in a single evening" after reading the prototype’s code.

Three things still go wrong, reliably. A weak design system poisons everything, because Claude reproduces its inconsistencies faithfully and much faster, which is why we spent the first six weeks cleaning up the library. Generated is not production, so the prototype repo stays separate, and one team that shipped from it directly paid for it the next sprint. And review does not disappear: someone still reads the diff and checks the frames, and faster output makes sloppy review more expensive, not less.