The Export Problem No One Talks About
You run your Figma file through an AI design-to-code tool. The layout comes out clean — flexbox is correct, spacing looks right. But something is off in the CSS.
The button that was supposed to be your 10% accent color? The output has it as #3b82f6. The sidebar background? #1e293b. The tool reproduced every hex value exactly. What it didn't reproduce was which color is the 60, which is the 30, and which is the 10.
The output code has no memory of proportions. A button and a hero background are both just hex values in CSS. Nothing in the exported stylesheet says "this color covers 60% of the surface area" or "use this one only on CTAs."
This is the gap that semantic variable naming solves — and it has to be set up in Figma before you touch the export tool.
Why Semantic Names Survive the Handoff
When Figma exports a component, it uses the variable name as the CSS custom property name. A variable named blue-500 becomes --blue-500. A variable named dominant becomes --dominant.
The difference is what the name communicates to the next developer (or AI assistant) reading the code.
/* Shade naming — no role information survives */
:root {
--blue-500: #3b82f6;
--gray-900: #1e293b;
--slate-50: #f8fafc;
}
/* Semantic naming — 60-30-10 role is explicit */
:root {
--color-dominant: #f8fafc; /* 60% — page surfaces, card backgrounds */
--color-secondary: #1e293b; /* 30% — navigation, sidebars, structure */
--color-accent: #3b82f6; /* 10% — CTAs, active states, focus */
}
When an AI tool reads the second stylesheet, --color-accent on a button reads as intentional. --blue-500 on a button is just a color choice with no structural meaning attached.
The semantic names are the mechanism by which the 60-30-10 proportions survive the transition from design to code.
Setting Up Semantic Variables in Figma
Start by generating your 60-30-10 palette at sixtythirtyten.co. You get the hex values for all three roles. Now bring them into Figma with the right naming structure.
Create a Variables Collection
- Open the Variables panel (grid icon in the top toolbar)
- Click + to create a new collection — name it
Color RolesorDesign Tokens - Under Color type, create three variables:
dominantwith value#f8fafc(or your 60% color)secondarywith value#1e293b(or your 30% color)accentwith value#3b82f6(or your 10% color)
You can nest these under a group: color/dominant, color/secondary, color/accent. Figma converts the / to a CSS property separator on export — color/dominant becomes --color-dominant.
Add Descriptions
Figma variables have a description field. Fill it in:
dominant→"60% — page backgrounds, card surfaces, white space"secondary→"30% — navigation, sidebars, table headers, section frames"accent→"10% — primary CTA buttons, active nav state, focus indicators"
These descriptions are picked up by tools that consume the W3C Design Tokens format. They also appear in Figma Dev Mode, so developers reading the design file see the role alongside the value.
Applying the Variables to Your Figma Design
With variables defined, apply them to design elements by role:
- Page background →
dominant - Card/panel backgrounds →
dominant(with opacity if needed) - Sidebar →
secondary - Top navigation →
secondary - Primary buttons →
accent - Active nav items →
accent(with reduced opacity for background) - Focus rings →
accent - Body text → Use a separate text variable or rely on contrast relative to surface
The Figma file now encodes the 60-30-10 distribution in its variable usage, not just in the palette definition.
Export Flow: Semantic Names Carry Through
When you export from Figma using any of the common methods — plugin export, Figma MCP Server, Builder.io, Locofy, or Anima — the variable names come with the values.
A component exported from Figma with dominant applied to its background produces:
.card {
background-color: var(--color-dominant);
}
Not:
.card {
background-color: #f8fafc;
}
The semantic variable reference survives the export. A developer reading the exported CSS understands immediately that cards use the 60% surface color. An AI assistant reading the exported stylesheet can infer role from name when generating new components.
The Final CSS Result
After export, your stylesheet has this structure:
:root {
--color-dominant: #f8fafc;
--color-secondary: #1e293b;
--color-accent: #3b82f6;
}
/* Components reference variables, not hex values */
.sidebar {
background-color: var(--color-secondary);
}
.page-background {
background-color: var(--color-dominant);
}
.primary-button {
background-color: var(--color-accent);
color: white;
}
Swap the palette by updating the three :root values. Every component updates automatically. The 60-30-10 proportions stay intact because the roles are encoded in the variable names, not in the component-level hex values.
What This Prevents
Without semantic naming, each AI export produces a flat list of hex values. A month later, when you need to update your accent color, you're grepping through generated CSS looking for every instance of #3b82f6 — and hoping none of those instances are ornamental elements that should stay unchanged.
With semantic naming, you change --color-accent in one place. Done.
The design intent — 60-30-10 proportions — is enforced by the variable structure, not by developer memory.
Where to Go from Here
For the mechanics of exporting Figma variables as JSON and transforming them into CSS and Tailwind config, see Figma Color Tokens to CSS Variables.
For wiring these variables into Tailwind v4 @theme or v3 module.exports, see 60-30-10 Tailwind Color Palette.
For the full CSS variables reference (usage patterns, dark mode, framework integration), see CSS Variables Color System Cheat Sheet.
For the full 60-30-10 rule — what the proportions mean and how they map to layout regions — see The 60-30-10 Rule: A Developer's Guide to UI Color Balance.
Generate your 60-30-10 palette, name the variables semantically, import to Figma. That's the sequence that keeps proportions intact from design through to production code.