How do I build a design system in Figma?

Build it in this order:

1. Tokens first, as Figma variables: raw values, then named roles on top.
2. Modes for light and dark, so one set of names holds both themes.
3. Styles only for what variables cannot hold, like full text styles.
4. Components built from those tokens, with variants for states.
5. Publish it as a library so every file uses the same source.
6. Connect it to code so the two never drift apart.

Most people start with buttons. That is backwards. A button built on hardcoded colours has to be rebuilt the day you add dark mode.

Figma describes design tokens as "a method for managing design properties and values across a design system." In Figma, you store them as variables: raw values like colours and numbers that can change with context. Figma's overview lists six variable types, including colour, number, string, and boolean.

Variables live in collections, and you can group them inside a collection. The key feature is aliasing: "A variable can reference another variable." That is what makes two tiers possible.

Figma's own guidance matches this. Primitive tokens "tell us what properties and values exist" and are for reference only. Semantic tokens "give us context on how the token should be used," and those are the ones you apply.

In my own token systems, every colour is authored in OKLCH as a primitive, and product work only ever touches semantic roles. Nobody picks a raw hex in a design or in code.

Figma's naming tips are short: make tokens easy to understand, use full words instead of abbreviations, be consistent with prefixes, and plan for growth.

The rule I follow on top of that: names describe role, never appearance. content/critical survives a rebrand. text-red does not.

My systems use four role families, which is a common pattern:

• surface for cards, inputs, and containers.
• fill for interactive backgrounds like buttons.
• border for edges and dividers.
• content for text and icons.

Then add a prominence (primary, secondary, brand) and, for interactive roles, a state (hover, active, disabled). For example, fill/brand-hover. Once the grammar is fixed, every new token is an addition, never a restructure.

A mode is one set of values for every variable in a collection. Figma lists uses like light and dark themes, other languages, and device sizes. The left-most column is the default mode, and layers set to Auto inherit the mode of their parent.

To add dark mode, you do not rename anything. Figma's guide says it directly: "There's no need to change the names of tokens." content/primary stays content/primary. Only the value behind it changes per mode.

Plan limits matter here. Per Figma's plan comparison, checked in October 2026:

Modes are also available on Education plans. As a student, check whether you qualify before you pay.

My personal system has two brands, each with light and dark, so four modes from one set of names. The role names are identical in every mode, so components never need to know which theme they are in.

Variables hold single raw values. Styles cover what variables cannot, like a gradient, or a text style that stores font family, size, and weight together. Styles can use variables, but variables cannot use styles. So bind your styles to variables wherever you can.

Then build components on top of the tokens. A few Figma features do most of the work:

• Variants group similar components in one container, called a component set. Figma's example: a button's properties "could be the size, state, or color."
• Component properties handle smaller changes without multiplying variants: Boolean (show or hide a layer, like an icon), Instance swap, Text, Variant, and Slot.

Build every state a developer will need: default, hover, pressed, disabled, focus, loading. A component that only has its happy path is half done.

Publishing. A library can hold components, styles, and variables. Libraries are only available on paid plans. When you publish an update, people using the library see a badge and can review and accept the changes.

Code syntax. Each variable can carry one code name per platform: Web, Android, and iOS. Set it to the exact name your codebase uses, so the token a developer sees in Figma is the token they type.

JSON in and out. Figma can import and export variable modes as JSON in the Design Tokens Community Group (DTCG) format. That format reached its first stable version, 2025.10, in October 2025, and the W3C community group lists Figma among the tools supporting it.

My own practice goes one step further. One source of truth generates everything. I author tokens in a build script, and it outputs both the Figma import files and the CSS. Figma is a read-only consumer: I do not invent variables inside Figma, because then the two sides drift. In the HeyOz system, the build fails if a semantic token contains a raw value, or if light and dark stop declaring the same names. That is the guarantee the system cannot quietly rot.

You do not need that setup on day one. Start with clean names and code syntax, and the pipeline can come later. For the handoff side, read my guide on design handoff to developers.

1. Create two collections in a fresh file: primitives (your raw colours and spacing) and semantic (roles that alias them).
2. Add a dark mode to the semantic collection and fill in every value. If you are on the free plan, check whether you qualify for Education first.
3. Build one button with variants for size and state, using only semantic variables.
4. Set code syntax on your semantic colours and inspect them in Dev Mode, or export them as JSON and read the file.

If you want to know why this skill matters for the role, see what a design engineer is.