Figma for Developers: Auto Layout, Variables & Dev Mode

Figma for Developers

Most quality lost between a design and a shipped interface is lost in translation — a spacing value approximated, a color typed by hand, a state nobody specified, a responsive behavior the developer guessed at. Very little of that is carelessness. It's that the design file contains more information than an image conveys, and knowing where to look turns handoff from interpretation into transcription.

The most useful thing to understand is that Figma's layout model is flexbox. Auto layout is display: flex with direction, gap, padding, and alignment — the same properties by different names. Once you see that mapping, a well-built file reads as a component tree with layout already specified, and the remaining work is the part that genuinely requires judgment: state, responsiveness, and interaction.

The corresponding thing to not do is copy the CSS Figma generates. It describes one frozen instance at one size, in absolute values, with none of your tokens.

TL;DR

Auto layout is flexbox. Direction → flex-direction, spacing → gap, alignment → justify/align.
Constraints define resize behavior for non-auto-layout children — the closest thing to responsive intent.
Variables are design tokens: typed, aliasable, with modes for theme and breakpoint.
Components and variants map to your component API — variant properties are usually your props.
Dev Mode gives measurements, a variable-aware inspect panel, and change tracking between versions.
Never paste the generated CSS. It's absolute values for one instance with no tokens.
What a file cannot tell you: interaction states, loading and error states, and real content edge cases. Ask.
The REST API and Code Connect let you automate token extraction and link components to real code.

Quick Example

Translating an auto layout frame to code — a direct, mechanical mapping:

The generated CSS is a description of one instance. The width: 384px in particular is the frame's current size, not a design decision — shipping it produces a component that doesn't respond to anything.

Core Concepts

Auto layout ↔ flexbox

Fill / Hug / Fixed is the piece that carries the most information and gets missed most often. A text element set to Fill is meant to expand; one set to Hug is meant to shrink-wrap. Reading these correctly is most of what makes a build match the design at sizes other than the one in the file.

Constraints

For children not in an auto layout frame, constraints define what happens when the parent resizes:

"Left and Right" means the element stretches with its container — effectively width: 100%. "Center" means it stays centered. These are the designer's statement of intent about resize behavior, and they're often the only responsive information in the file.

Variables and modes

Figma variables are the design-side representation of tokens:

Modes are the key feature: one variable, different values per theme, brand, or breakpoint — the same architecture as semantic tokens in code. Variables can also alias each other, giving you the primitive → semantic tiering directly in Figma.

Variable types are Color, Number, String, and Boolean. Number variables drive spacing and radii; boolean variables can toggle layer visibility, which is how designers build conditional states.

When variables are properly set up, Dev Mode shows you bg/default instead of #FFFFFF — which is precisely the information you need, and the reason it's worth pushing designers to use them.

Components and variants

This correspondence is worth actively maintaining. When the Figma variant names and your prop names match, conversations between design and engineering stop needing a translation layer, and a design review can be conducted in either artifact.

Note that Figma's State variant is documentation — CSS handles :hover and :disabled. What matters is that the values for each state are specified rather than guessed.

Dev Mode

Dev Mode is Figma's developer-facing view, and it provides:

Measurements between any two elements — hover and hold Option/Alt.
Variable-aware inspection — token names rather than raw values, where variables are used.
Asset export — SVG, PNG, at multiple scales.
Change tracking — a diff between the version you last built and the current one.
Annotations — designer notes on specific layers.
Code Connect — links a Figma component to your actual component's source and usage snippet.

Code Connect is the highest-value feature for a team with a design system: instead of generated CSS, Dev Mode shows the real import and JSX for the component, with props mapped from the variant properties. It requires setup per component and removes an entire class of "which component is this?" questions.

The REST API

This is how a token pipeline stays in sync: designers change a variable in Figma, CI pulls it, Style Dictionary regenerates outputs, and a PR opens. Tokens Studio provides the same round trip as a plugin with Git integration. See Design Tokens.

Best Practices

Read Fill/Hug/Fixed before writing any CSS

It's the responsive intent, stated explicitly, and it's the difference between a component that matches at 1440px and one that matches everywhere. Check it on every element whose width isn't obviously fixed.

Use tokens, not inspected values

Dev Mode says #2563EB; your code says var(--color-action-primary). If the design uses variables, the token name is right there. If it doesn't, look up which token that value corresponds to — and if it doesn't correspond to one, that's a question for the designer, not a hex value to hardcode.

Ask about the states that aren't in the file

Hover, focus, active, disabled, loading, empty, error, and "the text is three times longer than the mockup." Designs typically show the happy path at one size with ideal content. Every one of those unspecified states will be decided by someone — better it's a decision than an accident.

Push for variables and components in the file

A file built with variables, components, and auto layout is dramatically faster to implement than one built with detached rectangles. This is worth raising as a collaboration issue rather than absorbing as extra work each time — the fix is upstream.

Export SVGs and clean them

Figma's SVG export includes extraneous groups, IDs, and sometimes fixed dimensions. Run them through SVGO, set fill="currentColor" on icons so they inherit text color, and use a viewBox without hardcoded width and height so they scale.

Use Code Connect if you have a design system

The setup cost is per component and modest; the payoff is that every designer and developer sees the real component and its real props in Dev Mode instead of a CSS approximation. It removes the most common source of divergence between the system and its use.

Check the version history before rebuilding

Dev Mode's change tracking tells you exactly what moved between the version you implemented and the current one. Rebuilding from scratch because "the design changed" is usually unnecessary.

Talk to the designer

The highest-leverage practice in this entire topic. Fifteen minutes of conversation about intent, edge cases, and constraints prevents days of rework, and it's how the designer learns what's cheap and what's expensive to build. Handoff-as-document-transfer is where quality goes to die.

Common Mistakes

Pasting the generated CSS

Ignoring Fill/Hug

Hardcoding values that correspond to tokens

Building only the one state shown

Treating the mockup content as the real content

Rebuilding icons by hand

FAQ

Do I need a paid Figma seat?

A view-only seat is free and lets you inspect basic properties, comment, and export assets. Dev Mode requires a paid developer seat, and it's what provides measurement tools, variable-aware inspection, change tracking, and Code Connect. For anyone implementing designs regularly, the developer seat pays for itself quickly.

Should I use Figma's generated code?

No for CSS, and cautiously for structure. The generated CSS is absolute values for one instance with none of your tokens or responsive behavior. What's genuinely useful is reading it to confirm you understood the layout — if Figma says justify-content: space-between and you assumed gap, that's worth knowing.

How do I handle responsive designs when the file has one breakpoint?

Ask. Constraints and Fill/Hug settings tell you resize intent within a frame, and Figma's variable modes can express breakpoint-specific spacing — but a single-artboard file genuinely doesn't specify mobile behavior, and guessing produces rework. This is the most common gap between what a design file contains and what a developer needs.

What about AI design-to-code tools?

They've improved substantially at producing something structurally reasonable from a frame, and they're useful for a first pass on a static layout. What they consistently don't produce: your tokens, your component library, correct semantics and accessibility, state handling, or responsive behavior. Treat the output as a starting sketch to be rewritten against your system, not as shippable code.

How do designers and developers stay in sync on tokens?

One pipeline. Figma variables as the authoring surface, exported via the REST API or Tokens Studio into a token source in Git, transformed by Style Dictionary into CSS, iOS, and Android outputs. Both sides then reference the same names, and a value change propagates automatically. Manual copying always drifts. See Design Tokens.

What's the equivalent of Figma if my team uses something else?

The concepts transfer almost entirely. Sketch has symbols and smart layout, Penpot (open source) has flex layout and components, and Adobe XD has stacks and components. Every modern design tool converged on the same model — components, variants, flexbox-style auto layout, and shared tokens — because that's the model that maps to how interfaces are actually built.