Figma Make is Figma’s prompt-to-app tool: type a prompt or attach an existing design, and it generates a functional prototype or working web app inside the file. Every screen it produces ships as flattened CSS and unbound layers, not Figma Variables. That distinction matters the moment a Make output moves anywhere near a real product, because raw hex values and bare pixel numbers are exactly what a coverage audit exists to catch.
Figma’s own documentation confirms this directly: Make kits, the feature built to carry a design system into Make, still convert Variables into one flattened stylesheet rather than preserving token structure. This guide covers what a Make screen actually contains, how to export it without losing governance, and where scanning and tokenizing catches what generation leaves behind.
Related reading: the Figma design tokens guide covers Primitives and semantic architecture in full, Find Untokenized Values is the audit that catches exactly the raw values a Make export produces, and Figma MCP covers the adjacent case of AI reading a file that is already tokenized.
In short
- Figma Make (figma.com/make) is Figma’s AI prompt-to-app tool - it generates functional prototypes and web apps, not tokenized design files.
- Every Make output ships as flattened CSS and unbound layers; Figma’s own docs confirm Make kits convert Variables into raw values, not preserved token references.
- Copying a Make preview into Figma Design does not bind it to your design system - Figma states the layers “aren’t automatically tied to your design system.”
- Run a coverage audit and an untokenized-value scan on anything copied out of Make before it reaches production.
- The model behind a given Make project is a setting, not a constant - the token gap holds regardless of which model generated the screen.
What Figma Make actually is
Figma Make sits inside Figma as its own file type: open the AI chat, attach a design or an image, describe what you want, and Figma Make returns a working prototype or web app you can preview and refine through conversation. Figma’s own documentation describes it as “an AI-driven, prompt-to-app tool that lets you bring ideas and existing Figma designs to life as functional prototypes, web apps, and interactive UI.” We watched this exact pattern before Figma Make existed: hand an AI assistant a screenshot instead of structured tokens and it produces a plausible layout with invented values. Make’s prompt-to-app output follows the same shape - just packaged as a working app instead of a static mockup.
How a Make screen becomes a real Figma file
Getting a Make screen out of the chat window and into a design file is a copy-paste operation, not an export. On a paid plan, you can copy a Make preview as design layers and paste those layers straight into a Figma Design file - the fastest path from prompt to something a designer can actually edit on the canvas. Figma is explicit about what that paste does and doesn’t do, in its own Figma Make FAQs:
“Changes to the layers in Figma Design aren’t applied back to the Figma Make file, and the layers aren’t automatically tied to your design system.” - Figma Make FAQs
That single sentence is the entire governance problem in miniature: the layers exist, they look right, and nothing connects them to a color Variable, a spacing token, or a component in your library. From here the question stops being philosophical and starts being operational - what actually breaks when that gap reaches a real screen.
Why Figma Make output breaks token governance
A Figma Make screen fails a coverage audit the same way a hand-built mockup made with the eyedropper tool fails one: every fill, stroke, and text style resolves to a literal value instead of a bound Variable. That isn’t a bug in Make - it’s a direct consequence of generating UI as code and layers rather than as design-system-aware components, and it shows up the moment you scan the file. Teams that skip the scan ship the pattern straight into production: a checkout screen with a hardcoded #0d99ff sitting next to a dozen other blues that are supposed to be the same brand color, and nobody notices until a rebrand touches eleven of them.
What happens when Variables get flattened
Figma built Make kits specifically so a Make project could inherit npm packages, guidelines, and library Variables - and even that dedicated pathway does not preserve token structure. Figma’s own FAQ for Make kits states the limitation plainly:
“Make kits currently don’t support full extraction of design tokens. Instead, it pulls a subset of your variables and uses them to generate a global CSS file with raw values. This means variable syntax won’t be preserved exactly as defined.” - Figma, Get started with Make kits
In other words, the best-case setup - a published library, a Make kit, and guidelines telling the model how to use it - still lands you with a stylesheet of resolved values, not a semantic layer. If the fully-supported path flattens tokens, a plain prompt with no kit attached flattens them further. That gap is exactly where scanning and tokenizing earns its keep.
How to export screens from Figma Make without breaking your token system
Exporting a screen from Figma Make means copying the preview as design layers and pasting it into a Figma Design file - and the moment it lands, it should be treated as an untokenized import, not a finished design. Run the same scan you’d run on any hand-built frame: check what percentage of its fills, strokes, spacing, and typography are bound to Variables versus hardcoded, and flag what isn’t. The table below shows the gap directly.
Figma Make output vs a tokenized Figma file
| Property | Fresh Figma Make output | Tokenized Figma file |
|---|---|---|
| Colors | Flattened to raw hex or resolved CSS values | Bound to color Variables, e.g. background/default |
| Spacing | Bare pixel numbers baked into each layer | Bound to spacing Variables, e.g. space/4 |
| Typography | Inline font-size and weight per text layer | Bound to type Variables or shared text styles |
| Components | Rebuilt per screen as new layers | Reused component instances with real variants |
| Sync back to the file | One-way copy-paste; no live link to the Make project | Native to the file; audits and exports run directly on it |
None of those rows are a reason to avoid Figma Make - they’re a checklist for what to run before the output ships. This is the same workflow we built for hand-tokenizing legacy files, just pointed at a different source.
What a scan actually catches
We scan a selection or an entire page and extract every raw value - hex codes, spacing, border radii, typography, gradients, opacity - the same categories a Make export produces by default. A copy-pasted Make screen typically has none of that bound, which is exactly what our Coverage Audit is built to surface: what percentage of fills, strokes, paddings, and gaps are already on a Variable versus still a raw number. Below is what a scan catches in a typical flattened stylesheet from a Make export, next to what the same values look like once they’re structured as tokens.
/* Fragment of a flattened stylesheet copied out of Figma Make */
:root {
--spacer-3: 16; /* unitless - needs a calc() wrapper to become 16px */
--color-bg-primary: #0d99ff; /* raw hex, no reference to a token */
--radius-medium: 5;
}Run that same file through a DTCG export - the format maintained by the W3C Design Tokens Community Group - and the same three values become typed, named tokens that a coverage audit and a code pipeline can both read.
{
"color": {
"bg": {
"primary": { "$type": "color", "$value": "#0d99ff" }
}
},
"space": {
"3": { "$type": "dimension", "$value": "16px" }
},
"radius": {
"medium": { "$type": "dimension", "$value": "5px" }
}
}That structure is what makes the value portable: a Style Dictionary build reads the same JSON and produces CSS, SCSS, or Tailwind config without anyone retyping #0d99ff a second time. Once a Make screen’s raw values are rebuilt as Primitives and mapped up to semantic Atoms - bg/primary referencing the same blue every other button uses - the AI-generated screen stops being a one-off and starts being part of the actual system. Run a contrast audit against WCAG guidelines at the same time; a model optimizing for a screenshot-perfect result has no concept of a 4.5:1 ratio requirement.
Make kits, model choice, and other details worth knowing
A few details shape how bad the token gap actually is for a given project, and they’re worth knowing before you decide how much manual cleanup to budget for. Figma Make launched running on Anthropic’s Claude 3.7 Sonnet, with Figma noting at the time that it planned to add more models later - so the model behind any given Make project is a setting, not a fixed detail, and it doesn’t change the underlying problem. Whichever model generates the screen, the output is still unbound layers and flattened CSS; the token gap this article covers is architectural, not model-specific.
Make kits, custom skills, and MCP connectors are the features Figma has added to close this gap from the inside - a Make kit can carry npm packages, guidelines, and a subset of library Variables into a project, and MCP connectors extend Make’s context the same way the Dev Mode MCP server extends an IDE. Neither replaces an audit; they reduce how often you need one. On a Starter plan, none of this is available at all - Starter accounts can’t attach team libraries to bring in style context, which means every Starter-tier Make output starts from zero token coverage by definition.
When a Make screen doesn’t need a token audit
Not every Figma Make output needs to survive contact with a coverage audit. A prototype built to test whether a checkout flow makes sense, a throwaway exploration of three different empty-state layouts, or a client-facing demo nobody will maintain past the meeting - none of that needs tokens, because none of it is shipping. The exception ends the moment a stakeholder says “let’s just use this” about a screen that was never meant to be production UI, which is the most common way untokenized values quietly enter a design system.
Final verdict - Figma Make and Design Tokens
Figma Make is a genuinely fast way to turn a prompt into something a stakeholder can click through, and that speed is real. What it isn’t is a design-system-aware output: Figma’s own documentation confirms that even the dedicated Make kits pathway flattens Variables into raw CSS, and a copied preview isn’t tied to your design system by default. Treat every Make screen the way you’d treat a hand-built mockup from a designer who has never seen your token library - scan it, audit it, tokenize what’s worth keeping, and ship the rest as a prototype, not a component.
