Figma for design systems: Auto Layout, components and libraries

Being strong in Figma means building files that scale, not only screens that look good. A design system file is used by other designers every day and read by developers in Dev Mode, so its structure matters as much as its visuals.

This part walks through the Figma features a system leans on most, in roughly the order you will use them.

Auto Layout comes first

Nearly every component in a system is an Auto Layout frame. The settings to know:

• Direction: horizontal, vertical, or wrap for chip and tag lists.
• Gap and padding, bound to spacing variables rather than typed in.
• Resizing: Hug contents (size to the content), Fill container (take the space the parent gives) or Fixed.
• Min and max width, so a button grows with a longer label but only so far.
• Absolute position for an item that ignores the flow, such as a badge or a close icon.
• Grid, for rows and columns of cards or dashboard tiles.

Auto Layout follows the same mental model as CSS Flexbox, which makes it a shared language with developers:

Components and variants

A main component is the source; every copy placed in a design is an instance. Change the main component and every instance updates, while overrides such as label text are kept.

Variants group the forms of one component into a set, described by properties:

Type   = Primary | Secondary | Ghost
Size   = sm | md | lg
State  = Default | Hover | Pressed | Focus | Disabled

Alongside variants, Figma has component properties that change an instance without adding variants:

You can also expose nested instance properties, so a designer changes a child component’s settings from the parent’s panel without digging into layers. For areas that take arbitrary content, such as a card body or a modal’s content, a slot pattern works: a placeholder that designers swap for their own content.

Avoid variant explosion

Three types, three sizes, five states and an icon on or off already make 3 × 3 × 5 × 2 = 90 variants. Every new option multiplies the set, and the file becomes slow and hard to maintain.

Constraints and responsive frames

Layers outside Auto Layout use constraints (left, right, left and right, centre, scale) to decide how they move when the frame resizes. Pair them with layout grids set up per breakpoint, so a screen can be checked at mobile, tablet and desktop widths.

Organising files

Keep the system in its own library file, separate from product work. One common structure:

Design System (library file)
  ├─ Cover · Changelog · Getting started
  ├─ Foundations: Colour · Type · Spacing · Icons · Elevation
  └─ Components: Button · Input · Select · … (one page each)

Product file
  ├─ Ready for dev
  ├─ In progress
  ├─ Explorations
  └─ Archive

Publishing and branching

• Publish the system file as a library. Product files enable it and use its components and variables.
• Updates are opt-in. When the library publishes a change, product files see an update notice and accept it after review, so nothing shifts under a designer mid-task.
• Branch before big changes. On Organization and Enterprise plans, work in a branch, get it reviewed and merge it, much like Git.

Prototyping

• Triggers: on click, on hover, while pressing, after delay, key or gamepad.
• Animations: instant, dissolve, move in and out, and Smart Animate, which animates properties between layers that share a name.
• Variables and conditionals for richer prototypes: a counter, a cart, a toggle, a form that validates.
• Interactive components: build a hover state once inside the component and every instance has it.

Handing off: Dev Mode and Code Connect

Dev Mode shows developers spacing, token names, CSS and exportable assets, and lets designers mark frames as ready for dev. Annotations add measurements and notes right on the design.

Code Connect links a Figma component to the real component in code. Instead of generated CSS, Dev Mode then shows the snippet a developer would actually write:

<Button variant="primary" size="md">Save changes</Button>

This only works when the Figma property names match the code prop names, which is a theme Part 4 returns to.

Next in the series

Knowing the tools is half of it. Part 4 is about building a component properly: auditing what exists, defining anatomy and states, aligning the Figma and code APIs, and writing a full Button spec.