by In my previous post, I tested Figma’s Code to Canvas feature – sending a running UI from the browser into Figma as editable layers. At the end, I mentioned that the other direction, Figma to code, felt more useful from a developer’s perspective.
So my colleague Gabriel Quaresma and I decided to actually test it. We ran separate experiments, hit different walls, and now I can tell you what this workflow actually looks like when you leave the demo scripts behind.
My experiment: applying design changes to an existing project
I had a hospital dashboard project – React, Tailwind, lucide-react for icons – with the code split into components: Sidebar, Header, StatsCards, RecentPatients, and so on. A normal codebase, not a single-file toy project.
I changed the sidebar design in Figma – colors, layout, items – and then asked Claude Code to read the specific Figma frame and apply those changes to the existing Sidebar.jsx component.
It worked. Claude read the wireframe through the MCP, understood what changed, and updated the component. But here’s what I learned getting there:
You must be specific. Link the exact wireframe node. If you pass the Figma file URL and vaguely ask for changes, it either doesn’t work or gives you inconsistent output. Point to the exact node, tell it which component to update, and it delivers.
This makes sense if you think about it. You wouldn’t tell a human developer "look at the Figma file and figure it out." You’d say "the sidebar changed, here’s the frame, update the sidebar component." Same thing here.
Quaresma’s experiments: starting from scratch
Quaresma took a different approach. He grabbed designs from Google’s Stitch – an AI design tool – copied them into Figma, and asked Claude to implement them from scratch.
Experiment 1: HTML, CSS, and JavaScript
He linked a Figma wireframe and asked Claude to implement it using HTML, CSS, and JavaScript. Claude put everything into a single index.html file. Styles, markup, scripts – all in one place.
The output matched the Figma design exactly. But it didn’t follow any structural best practice. No separate files, no modules. Claude did the minimum to satisfy the request.
Which, if you think about it, is exactly what was asked. "Implement this using HTML, CSS, and JavaScript" doesn’t say "organize it into separate files with a build system." The tool is literal. It cares about getting the visual output right, not about how you’d organize a real project.
Experiment 2: React and Tailwind
For the second experiment, Quaresma asked Claude to implement a different wireframe using React and Tailwind CSS v4. This time Claude scaffolded a full Vite project, installed dependencies, configured the Tailwind plugin – the whole setup.
But all the UI code went into a single App.jsx file. 170+ lines, everything inlined. It created helper components like ProductCard and ProductRow, but they lived in the same file. A real project would split those into separate files, maybe add a router. Claude didn’t think about that because nobody asked it to.
The design still matched the Figma wireframe accurately. That part is consistent – the visual translation is solid.
The mobile viewport problem
The wireframe Quaresma used for the React experiment was a mobile design – a 390px-wide frame for a ceramics shop called "Clayful." Claude generated exactly that: a mobile-width container, centered on the page, with a fixed max-w-[390px].
It didn’t make it responsive. You can’t hand Claude a mobile wireframe and expect it to figure out that the layout should also work on desktop. It reproduced what it saw: a mobile screen. If you want responsive behavior, you need to provide wireframes for multiple breakpoints or say so explicitly.
This one caught us off guard at first, but it makes sense. Claude translates what’s in the design, not what you meant the design to imply.
What we learned
Specificity is everything. I keep coming back to this. The exact Figma node, the exact component to update, the exact constraints you care about. Vague requests get vague results.
It does minimal effort by default. Ask for HTML, you get one file. Ask for React, you get one component. If you want separate files, responsive layouts, or specific conventions – say so. Claude won’t assume good practices on its own. This isn’t necessarily bad. I’d rather have a tool that does what I ask than one that guesses what I want and gets it wrong.
The visual translation is accurate. Both Quaresma’s experiments produced output that matched the Figma designs. Designers and PMs who care about pixel fidelity will appreciate this. The gap between "what’s in Figma" and "what renders in the browser" was small in every test we ran.
Existing projects work better than starting from scratch. When Claude already has a codebase to reference – how files are organized, how components are named – it follows those patterns. My hospital dashboard experiment went smoother than Quaresma’s greenfield ones because Claude had context. If you can, start with a project that already has structure, and let Claude fill in the pieces.
Design libraries are still a problem. Quaresma tried a few experiments where the Figma design used a component library with its own design system. The results were not good. Mapping Figma components to the right library components requires context that the MCP doesn’t provide well yet. This probably deserves its own follow-up post.
The quota problem
Here’s what actually makes experimenting frustrating: Figma’s MCP quota on the starter plan is about 6 requests per month. Each get_design_context call is one request. Each screenshot is another. You burn through your quota in two experiments, maybe three if you’re careful.
For a feature that’s supposed to change how designers and developers work together, this is a wall. You can’t iterate, you can’t try different approaches, you can’t build intuition for the tool – because you run out of calls before you learn anything. If Figma wants people to actually adopt this, the free tier needs room to experiment.
Where this leaves us
Figma to code works. The better your instructions, the better the output. That’s it. No mystery.
I think of it like working with a very capable but very literal colleague. They’ll build exactly what the wireframe shows. If you want architecture, responsiveness, or conventions – you have to spell it out.
For applying design changes to an existing codebase, I’d use this today. For generating entire projects from scratch, it gives you a faithful starting point that you’ll need to reorganize.
The Figma MCP is early. The quota, the design library gap, the occasional weirdness – these will get better. But the basic loop already works: the designer changes a frame, you point Claude at it, Claude updates the code. That alone saves me time.
Thanks for reading!
We want to work with you. Check out our Services page!
