Figma Variable Settings for Design-to-Code Workflows

I was teaching Claude to compare Figma variables with my codebase tokens when I stumbled on something that changed how I think about design systems.

Same exercise I'd done a dozen times. Point the model at the design system, point it at the code, ask it to map one to the other. Every time, I had to explain the naming convention manually. "The Figma variable background/surface maps to the token backgroundSurface. Sometimes they match, sometimes they don't. You need to figure it out."

Then I filled in code syntax for one variable. Just testing. That field in the Details panel I'd been ignoring: "Code syntax: Web". I typed backgroundSurface.

Ran the comparison again. The model found it instantly. No explanation. No translation layer. The metadata was already there.

I added code syntax to ten more variables. Same result.

Over the past few months I've been talking to designers about AI design-to-code workflows. Designers at startups, agencies, big companies. I check community design systems regularly. Nobody's using code syntax. A few people know it exists. Almost nobody knows why it matters.

That's when I realized: this feature was built for a workflow that didn't quite exist yet. And now that workflow is here.

Without code syntax, Figma exports variable names in its own format: background/surface, foreground/base, border/system/success. Slashes for hierarchy, lowercase for readability.

Your codebase doesn't use that format. You use camelCase: backgroundSurface, foregroundBase, borderSystemSuccess.

The gap seems small. But when you're working with 240+ variables, that gap becomes a translation tax.

Every time a model needs to map design to code, it has to guess. Is background/surface the same as backgroundSurface or surfaceBackground? Is foreground/interactive/primary mapped to foregroundInteractivePrimary or primaryInteractiveForeground?

Sometimes it gets it right. Sometimes it doesn't. Either way, you're burning time—yours explaining the pattern, the model's figuring it out, the developer's verifying it's correct.

Code syntax eliminates this entirely. You fill in one field per variable. background/surface becomes backgroundSurface. foreground/system/danger becomes foregroundSystemDanger. The model reads it directly from the metadata.

The cost of not doing this compounds.

Dev time spent translating variables to tokens during handoff. AI token usage trying to pattern-match naming conventions. PR comments asking "which token is this supposed to be?"

I built a Figma variable generator skill to automate adding code syntax across 240+ variables. It worked, but I was missing proper context in the prompts. Easy fix—the skill works as intended. The point is: this metadata is infrastructure now, not nice-to-have documentation.

When the Figma MCP can read code syntax directly, when models can compare design and code without translation, when developers can see the exact token name in dev mode. That's when this feature shifts from optional to essential.

If Code syntax tells machines what to call things. Descriptions tell humans what things mean.

Your semantic naming might be clear to you. background/sunken, background/surface, background/overlay—you know these represent depth levels. But does everyone?

A new developer joining the team sees three background options and has to guess. Is sunken below surface, or is surface the base? Does overlay sit above surface or above raised?

A description field solves this in one line: "Background for sunken or recessed areas." Now it's unambiguous.

This matters for AI too. When a model is trying to decide between backgroundSurface and backgroundSunken for a card component, the description provides disambiguation. Not just "what is this token called" but "what is this token for."

The difference between foreground/base and foreground/subtle might be obvious from the color values in light mode. In dark mode, that logic inverts. The description—"Primary text color with highest contrast" versus "Secondary text color for less prominent content"—makes the intent explicit regardless of the values.

If you're building AI-ready design systems, descriptions are cheap insurance. One sentence per token. Minimal effort. Maximum clarity when it matters.

If you have semantic color tokens for backgrounds, you can scope them to only show up in fill properties. Your spacing tokens only appear in gap and padding fields. Your border radius tokens only show in corner radius.

Without scoping, you're scrolling through every token in your system every time you need to set a border radius. With scoping, you see exactly what's relevant.

This isn't about AI workflows. This is about not drowning in your own design system. If you're not using scope, start there.

These three settings were always there. But their value proposition just changed.

Design systems used to be documentation. A source of truth for humans. Designers reference them to stay consistent. Developers reference them to implement correctly. The system exists to be read and interpreted by people.

That model is shifting. Design systems are becoming APIs. Machine-readable infrastructure that tools can consume directly.

When Figma's MCP can read your variables and compare them to your codebase, code syntax isn't a convenience—it's a requirement. When a model needs to generate a component using your design tokens, descriptions provide the context that prevents it from choosing backgroundSurface when it should use backgroundRaised. When developers are working in dev mode, seeing the exact token name removes ambiguity from the handoff.

The features didn't change. The workflow around them did.

If you're working on design-to-code workflows; with or without AI. This metadata matters now. Not as nice-to-have documentation, but as essential infrastructure.

Code syntax eliminates translation between design and code. Descriptions provide intent when naming alone isn't enough. Scope keeps your workflow manageable.

Start with code syntax. That's where the translation tax is highest. Add descriptions where semantic names need clarification. Use scope if you're not already. The workflow that makes these features essential is already here. Most design systems just haven't caught up yet.