Speed up UI generation with AI-ready Figma design
Generating UI from a Figma design only works if the design is structured for it. Much of the work sits on the Figma side, long before AI is involved.
When a design and its design system are not ready for AI, the cost lands on the frontend team: days spent correcting tokens and hardcoded CSS values, restructuring components that were never built to be reused, and deciding what a messy Figma file was actually meant to express. And an AI model given an unstructured design fills those gaps by guessing, so the mistakes it makes are different every time — which makes them slow to spot and slower to trust.
So the preparation happens in Figma, not in the prompt. The sections below cover what has to be in place before anything is generated: how design tokens are structured, how components declare their properties, how the design is mapped to the code, and how the files are organised.
Design tokens in three layers
Primitive tokens hold the raw values. Theme tokens sit on top and switch per brand. Semantic tokens reference primitives or theme values and switch between light and dark. Components use semantic tokens only.
- primitiveraw values
- themeper brand
- semanticlight / dark
The point of the middle layer is that a brand switch never touches a component. Only the theme collection changes, and everything downstream resolves to the new values.
None of this holds unless the tokens reach the code automatically. Every Figma variable corresponds to one CSS variable, generated by a script instead of copied by hand — a custom Figma plugin, which is worth building in-house because it can follow the naming and structure the codebase already uses.
When designers add, rename, or remove a variable, the change arrives in the repository as a diff. A frontend developer reviews it and updates the components that depend on it. That review is the point: nothing changes silently, and a renamed token becomes a line in a pull request instead of a colour that quietly stopped resolving.
Components with explicit properties
Each Figma component exposes properties, and its variants show how it renders for each combination of values. That variant set is the contract the React component has to match. Where the implementation differs from the Figma structure, Code Connect reconciles the two.
Figma Code Connect
Code Connect maps every Figma component to its React implementation through a *.figma.ts file kept next to the component. Figma then shows the real code snippet instead of generic markup, and the AI reads that mapping to generate code that fits the existing API.
This is the step that changes generation quality the most. Without it, a model infers an API from the visual layout and invents prop names. With it, the mapping is explicit.
A predictable file structure
Every product file is linked to the shared component library. Each page is a Figma section with mobile, tablet, and desktop frames, carries annotations, and uses tokens rather than raw colour values.
The annotations matter more than they look. They carry the information a static frame cannot show: what is interactive, what the empty and loading states are, and how a layout should behave between breakpoints.
Two Claude Code workflows
One workflow builds components, the other builds pages. Both run skills that read the tokens, the Figma structure, and the annotations, plan the architecture, and then write the code against the project's React conventions. A separate agent reviews the result.
Reviewing generated code is a real step, not a formality. The agent catches the same things a colleague would: duplicated markup that should be a component, tokens bypassed in favour of a literal value, missing keyboard handling.
The result
Component development moved from days to hours. The saving does not come from the model writing faster — it comes from removing the ambiguity it would otherwise have to guess at.