Every AI design tool demo ends at the same place: a beautiful generated page. Production starts one step later, and that step is the one I want to talk about, because I learned it the hard way rebuilding the design system of my own site. My position after using Figma Make across real client and personal projects: generate the pages first, extract the design system second, and do not call anything "production" until every hardcoded value in the output has become a named token. The generation is the easy 30 percent. The token discipline is what survives handoff.
Why I trust tokens more than taste
Here's the experience that anchors this whole workflow. When I rebuilt my blog's front end, I moved every surface, text, and interactive color onto a semantic CSS custom-property ramp, with contrast measured rather than assumed: body copy targets WCAG AAA, everything else AA. The exercise surfaced a bug taste alone would never catch. My brand green carries white text at a contrast ratio of 1.9:1, which fails every accessibility bar there is. The fix was a dedicated token, an "on-link" ink color that flips per theme, landing at 10.0:1 in dark mode and 5.8:1 in light. One token, defined once, correct everywhere.
No AI design tool would have flagged that, because the page looked fine. It rendered, the green was on-brand, the text was readable to a healthy eye in good light. This is exactly the class of problem that separates "generated" from "production": the generated artifact encodes decisions as raw values, and raw values can't be audited, themed, or fixed in one place. Tokens can.
Keep that in mind through everything that follows, because Figma Make is very good at producing raw values.
The prep work most tutorials skip
Figma Make generates from prompts, and prompt quality is a direct function of how well you understand your own application before you type. I build three artifacts before touching the tool:
A page inventory. Every screen, named and described in one line. "Dashboard: KPI cards, activity feed, quick actions." Boring, and it prevents the failure I see constantly: designing screens the app doesn't need while forgetting the ones it does.
A component census. For each page, the components it requires. Writing this list exposes the shared patterns before anything is drawn: stat cards and table cells share typography, filter chips and buttons share states. The census is your design system's scope, discovered rather than invented.
A reference set with intent. Not a mood board of pretty screenshots. Four to six production examples per component type, so prompts can say "sticky headers like a database view" instead of "a nice table." Specific references are prompt engineering for visual tools, and the output gap between vague and specific prompts is enormous.
An hour of this prep reliably saves a day of regeneration.
Generate in sequence, not in bulk
Order matters because each generated page becomes context for the next. My sequence: navigation first, since it appears everywhere and sets the visual tone. Dashboard second, anchored to the established nav. Data-heavy pages third, with every state prompted explicitly: hover, selected, editing, loading, empty, error, sorted. Tables are where AI generation stumbles most, precisely because states are where the interface complexity actually lives. Secondary components last, inheriting the established language.
Expect the first pass to be structurally right and stylistically 70 percent there. I budget roughly 30 percent of design time for generation and 70 percent for refinement, and that ratio is still a massive win, because the 30 percent replaces the blank-canvas phase that used to consume most of the timeline. I covered how this generation-then-refine loop connects to code in my Claude plus Figma design system workflow, and the same principle applies here: AI output is a draft with good bones.
Extract the system after the pages, not before
This inverts the textbook order, deliberately. Classic guidance says build the system first and compose pages from it, and for a large team with dedicated system engineers that's right. Working solo or small, designing pages first gives you something better than theory: usage evidence. You extract into the system only the components that actually recurred and only the values you actually used. The system becomes a record of real decisions instead of a speculative library.
Once pages are refined, I have Figma Make generate what I call a minimum viable design system: the palette as used, the type scale as used, spacing, radii, and core components with full state coverage. Then a second pass for the predictable gaps, alerts, toasts, empty states, pagination, modals. My first attempt at this years ago produced 47 component variants of which I used 12; start minimal and let real pages pull components into existence.
One practical warning from painful experience: a fully detailed system can be too large to import into downstream tooling in one piece. Split it into foundations, core components, and complex components, and move them separately.
The token conversion pass, where production happens
Figma Make's code output arrives with hardcoded values everywhere: hex colors, pixel font sizes, magic-number padding. Shipping that is technical debt wearing a velocity costume. The moment someone asks to darken the primary color, you're doing find-and-replace across fifty files.
So before any generated code reaches a repository, I run a conversion pass: every color, type, spacing, and radius value becomes a CSS custom property, with the naming convention decided up front and stated in the prompt. On my own site that ramp is exposed to Tailwind through rgb(var(--token) / <alpha-value>), so utilities and tokens stay one system instead of two. The type scale uses fluid clamp() values anchored at 390, 768, and 1440 pixels, which means responsive typography is a property of the system, not of individual components.
And bake in theming from day one. Both light and dark values per token, always, even if dark mode ships later. I've retrofitted dark mode onto an untokened codebase three times in my career, and the reason my blog rebuild went smoothly is that I finally refused to do it a fourth. If a component subtree needs to opt into the opposite theme, a single class that re-scopes the ramp handles it; I used exactly this to fix a shared pagination partial whose links rendered at 1.79:1 contrast when a dark-styled component met a light page.
The AI handles maybe 80 percent of the token conversion correctly when prompted with your naming convention. Review the rest by hand. It's the highest-leverage hour in the whole workflow, and it's also where tools like the Figma MCP inside Claude Code start paying off, since a tokened system is the thing an agent can actually reason about and extend.
Two paths from design to code
For solo work, direct code export after the token pass is legitimate and fast. For teams, keep Figma as the source of truth, structure the file into system, screens, states, and handoff notes, and let developers rebuild against the system through inspection or MCP tooling. The team path is slower and produces fewer integration fights. I use both, and the deciding factor is simply how many people will touch the implementation. Either way, the goal is the one I keep coming back to when I use Claude Code as a UI design partner: encode the constraints in the system, so nobody has to ask about them in Slack.
What actually changes
Across the projects I've run this way, handoff time dropped by more than half, and the improvement clients notice isn't speed, it's coherence. Nobody says "nice tokens." They say the interface feels more polished than expected, and they can't articulate why. The why is that fifty micro-decisions were made once, in the system, instead of fifty times, inconsistently, across pages.
A design system is infrastructure, not decoration. AI generation made the infrastructure cheap enough that skipping it no longer saves meaningful time, while the debt from skipping it costs exactly what it always did. Generate the pages, extract the system, convert the values to tokens, measure the contrast. In that order.
If you'd rather have this done for your product than do it yourself, a production design system built on measured tokens is one of the things I ship for clients; the details are on my services page.
