This is the stretch nobody films. The demo ends at the screenshot; the job ends about a week later, in a Figma file that someone else has to be able to open without you in the room.
It's also where roughly 40% of the work lives, and where most AI-assisted design quietly falls over — not because the screens are bad, but because nothing in them is addressable.
Import destroys the names
Bring generated markup into Figma and everything arrives as a frame inside a frame inside a frame, with names that mean nothing. The structure survives. The meaning doesn't.
The instinct at this point is to start componentising from what's on the canvas — find a button in a screen, make it a component, move on. Don't. That tree is a rendering artefact. Build your library from it and you inherit every accident in it: wrapper divs promoted to components, layout containers baked into masters, the same element modelled three different ways because it appeared in three different screens.
The source markup is the specification. It knows what each thing is. So the first move is reading it and producing a record of what should exist and what it should be called — then renaming against that record, then componentising. Rename first, componentise second. Reversing those two costs more than any other ordering mistake in this stage.
Library first, screens second
Masters get built in a clean library section, not harvested from inside screens.
The difference shows up in what ends up inside the component. Harvested masters carry their surroundings — a padding wrapper that belonged to the screen, a demo label, a background that existed to make it visible on a dark canvas. Those things then travel into every instance, and six months later somebody is asking why every card has eight pixels of phantom padding.
Same-structure things get grouped into a variant set rather than left as separate components. A button that arrives as five unrelated components instead of one set is the single most common breakage I hit here, and it has to be fixed at this point, because everything downstream references it.
Bind at the master
Colour, type, elevation, effects — bound at the master, then the loose layers that live outside components get handled separately.
Two rules that sound obvious and are broken constantly. First, binding changes only the style property; it must not disturb size, position, layout behaviour or constraints. Second, no snapping to the nearest value. A checker that offers to fix everything is offering to guess, and a guess that lands on the visually closest value is exactly how a system quietly acquires meanings nobody chose. Use the checker to find things. Decide the fixes yourself.
Swapping will eat your real content
When screen layers get swapped to instances, the overrides carry real copy — actual names, actual prices, actual text someone wrote.
A bulk swap run without care replaces all of it with the master's placeholder content, and you find out screens later. This is the single most expensive small mistake in the whole stage, because the damage is silent, distributed, and only visible if you happen to look at the right screen.
So: one representative screen first, checked with your own eyes, before and after. Then the rest. Every time. The pilot feels like a waste when the batch is right there and the agent sounds confident — that confidence is the tell, because it reports identically whether it produced one correct thing or a hundred wrong ones.
Where MCP earns its place
Some component structures are more complicated than a scripted build can shape — nested variants, states that interact, structures that need judgment about what belongs inside and what doesn't.
That's where driving Figma directly through an agent connection pays: building the component with its real states, then swapping it into the screens, with a person deciding the shape and the tool doing the repetition.
What it doesn't do is see the result. It reports that the instruction ran, not that the screen looks right. So the loop stays the same: it builds, you look, then it repeats.
Then flip the mode
Before calling any of this done, switch themes and compare against the version you already approved.
If Figma is wrong and the source was right, the binding is wrong — fix the binding. If both are wrong, the problem is upstream in the system itself, so fix it there and bring the change forward. What you must not do is patch the Figma file alone, because you've now got two sources of truth that disagree, and the file will win every argument until someone rebuilds it.
What this buys, honestly
Done properly this removes something like 70–80% of the manual finishing work. Not 100%. There will be errors, there will be a pass where you fix things by hand, and anyone promising a single click to a perfect file has not shipped one.
But 70–80% of the least interesting work in the project is a real number, and it's the difference between a workflow that ends at a pretty screenshot and one that ends at a handoff.
What this doesn't solve
It doesn't decide what should be a component. That's a judgment call about what will repeat and what won't, made before there's evidence either way, and I still get it wrong on unfamiliar product types.
And "ready for handoff" is a safer claim than "a developer can start immediately" until a developer has actually opened it. I've learned to say the first one.
The whole thing, recorded on one real project
I recorded the full path end to end — brief, structure and flows, generated screens, locked token system, Figma with real components and variables, clickable prototype, developer handoff — on a single project, breakages included:
Claude AI UI/UX: Complete Workflow from Brief to Figma — the same path on one real project, brief through to a Figma handoff.
If you've found a reliable way to keep real content through a bulk swap, I'd like to hear it. That one still costs me time.
Top comments (0)