How the prototype travels from code to Figma without losing the real component

How the prototype travels from code to Figma without losing the real component

Editor's note: this article identifies Christine Vallaure as a "product designer" in several passages, including the attribution of the direct quote. This credential was not found in the original UX Collective post used as the source, which identifies her only by name and as the author of the text. The rest of the facts, figures, and technical quotes in the article were checked against the source and are accurate.

Product designer Christine Vallaure describes a flow where the same prototype moves between code and Figma without anyone having to redesign anything, as long as the components on both sides have exactly the same name.

Product designer Christine Vallaure describes a flow where the same prototype moves between code and Figma without anyone having to redesign anything, as long as the components on both sides have exactly the same name.

Product designer Christine Vallaure sums up well the dilemma facing anyone designing products today: either you prototype in code with AI and gain fidelity, or you stay in the Figma canvas and gain comparison speed. In a post published on November 11, 2026 on UX Collective, she describes the decision she made to stop choosing: making the design system components exactly the same in both environments, so a prototype can be born on either side and cross over to the other without anyone redesigning anything.

The name she gives to this is In-System Design: for each task, you choose the surface that solves it best (code or canvas), but you never leave the system to get there. The quote that sums up the point:

This is what I call In-System Design: for every task you pick the surface that does the best job, and you never leave the system to get there.

Christine Vallaure, product designer and author

Why the canvas is still worth sticking with

Vallaure cites a 2010 Stanford study on parallel prototyping: designers who placed multiple versions side by side produced better work than those who refined one version at a time, with more clicks on live ads and higher expert ratings. The study predates any generative AI, but the logic applies directly to the prompt box: it resembles the second group, one screen, then an improved version of the same screen, rather than three parallel alternatives.

In short: good product comes from comparison, not just refinement, and the canvas remains the cheapest place to compare. The problem was never the canvas: it was having to choose between it and real code.

The single condition: same name, same property

The entire flow depends on one simple, rigid rule: every Figma component must have the exact name and properties of the component in code. In Vallaure's setup, code is the source of truth, so the Button component in Figma has a variant property with the values primary, secondary, ghost, and danger, in the same spelling and case used in the code, without "Style: Filled" or any translated name.

With that aligned, moving a screen becomes a lookup, not an interpretation. A ghost button on the canvas IS the <Button variant="ghost"> in the code. When Vallaure asked an AI agent to rebuild a booking flow from Storybook inside Figma, it placed 21 library components without making a single visual decision. If the names don't match (Figma says "Size = Medium", code says size="md"), someone has to interpret, and an AI interprets with great confidence, incorrectly.

How the prototype crosses over in practice

For the complete flow, from code to Figma and back, Vallaure lists what needs to exist: a published Figma library identical to the code in names and properties, an empty prototype file with that library connected, an MCP connection to Figma (she uses Figma Console MCP, by Southleft), a real AI agent (not a chat) such as Claude Code, Codex, or Cursor, a way to prototype in code with the real components (Storybook MCP or a design system's own MCP), and a design branch isolated from production.

The prompt she uses to send a prototype from Storybook to Figma is direct:

In my Storybook there is a prototype called Course sign-up. Send it over
to the open Figma file called Prototype. Rebuild it with my Figma
components, set up exactly the same way as you see it in code. Add
comments to the prototype for anything I need to know, and put a little
note next to it: components you could not build, gaps, anything else
I should know.

What comes back are the screens in Figma, already connected as a clickable prototype, with comments where Figma cannot show the behavior on its own and a note alongside listing what was assembled by hand.

The shortcut that became a habit: Cmd+Y

Vallaure's favorite trick throughout the whole flow is pressing Cmd+Y (Ctrl+Y on Windows), which switches Figma to wireframe view: every library component instance shows up in purple, and anything drawn by hand does not appear. In a second she knows whether she's looking at the real system or a drawing of it. In her example, the top bar (which her sample system doesn't yet have as a component) shows up uncolored, exactly as the note had already warned.

On the way back, from Figma to code, the AI reads each instance by its originating library component and configured properties, not by the layer name. Any element that is not a library instance goes onto the pending list instead of being silently recreated as new code.

What the trip picks up along the way

Vallaure expected to save time with this flow. She did not expect it to catch bugs, but that happened repeatedly, because each crossing works as a second pair of eyes on the system:

• A 21-pixel difference. A sign-up screen came out 21 pixels shorter in Figma than in Storybook. The initial suspicion was that Figma was wrong; actually, two form components in the code left the help text inside a paragraph that kept the browser's default margin, and no automated check flagged it because technically no rule was broken.
• Figma fixing the flow. A modal in Figma had no slot to receive a form. Instead of forcing it, the flow changed: the form became its own step and the modal became just a confirmation. The code kept that change.
• A bad habit copied faithfully. A top bar used an empty spacing layer to push elements, because the code did the same thing in three places pasted together. In the code nobody had noticed; on the canvas, an empty layer shows up for what it is, and it could be fixed.

And for those who don't have half the code ready yet

Vallaure acknowledges that most teams don't have a Storybook MCP or a design branch today. Even so, you can do just the canvas half: prototype directly in Figma with AI, using only the connected library, and deliver something a developer reads as real components, not as a drawing of components. If the naming is aligned, delivering that prototype tends to be easier to rebuild than code generated by vibe coding with no reference to the system at all.

A question that naturally comes up: what if the AI invents a new component inside Figma? In her setup that hasn't happened yet, because the prompt explicitly asks it to use only the connected library and to flag when something needs to be invented. Even so, any invention would stay trapped inside the prototype file, the only one the MCP touches; the main library, used by the whole team, is never altered. In practice, this works as an accidental safeguard against misalignment. The most common mistake, according to her, isn't even the AI's: it's forgetting to accept library updates inside the prototype file, causing the AI to build with last week's components.

The manifest that solved the speed problem

After repeating the same prompt for the third time, Vallaure packaged the instructions into a skill (a set of instructions the AI loads automatically when that type of task comes up). The improvement that made the biggest difference was a Figma manifest: a small JSON listing every library component with its properties and the internal key Figma uses to place it.

Before the manifest, a reconstruction spent most of its effort combing through the entire library listing (around 59,000 characters) just to find a text style; with the manifest, it became a lookup of a few lines, and it also started working as a check that Figma still matches the code.

Other skill improvements: gaps flagged right in the layer name itself (something like GAP, not just in a separate note); layout names drawn from the code's vocabulary (stack, cluster, split, columns, grid, page) applied to Figma's auto layout frames; and a canvas note always following the same structure, with four categories: real library components, hand-built items, points where Figma and Storybook diverge, and suggestions for new components. The skills are public on Vallaure's GitHub, with the usual warning: read before running, because a skill executes code on your machine.

What the flow doesn't eliminate: the handoff

All of this happens inside a design branch, an idea Vallaure credits to TJ Pitre: a parallel copy of the code where the designer prototypes, sends to Figma, works freely, and sends back, with no risk of breaking production. This branch is never merged into the main system; when a prototype is approved, a developer rebuilds the accepted parts in a new branch, going through the team's normal checks before any human approval.

The question left for anyone leading a design system: if the code is going to be rebuilt anyway, why does working across two surfaces pay off? Because most of the decision has already been made by the time the prototype reaches the developer: nobody has to negotiate anymore what a button is or which variant to use, so they transcribe decisions instead of reverse-engineering an image. What's left to discuss are the real gaps, like that hand-built top bar showing up in every prototype, a sign that the system is asking for a new component, not a detail tweak.