What Are Design Tokens?

Design tokens are design decisions stored as named data. Each token pairs a name with a value — brand-600 holds one exact blue, space-4 one exact gap — and the tokens live in a tool-neutral file from which every consumer format is generated: CSS for the web, variables for Figma, resources for native code.

That definition compresses three ideas, and each carries part of the weight: a token is a decision with a name, tokens compose through references, and the composed system exports to every consumer. This article — the opening piece of our design tokens guide — builds the definition up one step at a time.

What does “a design decision with a name” mean?

Every product accumulates design decisions: the brand blue is this hex, body text is 16px, cards get this much padding. What varies is where those decisions live. In many teams they live in someone’s memory, in a slide deck, or in a PDF style guide — places a person can read but nothing can execute. A token moves the decision into data:

"brand-600": { "$value": "#2563eb", "$type": "color" }

The name is the decision’s handle; the value is its current answer. Once a decision is data, tools can do what tools do: validate it, diff two versions of it, generate code from it, find every place it is used. A PDF that says “primary blue, use for buttons” needs a human interpreter; a token file states the same decision in a form a build step can act on.

How do tokens become a system?

Through references. A token’s value can be another token’s name, and that single mechanism turns a flat list of constants into composed decisions. The common convention is layered: semantic tokens name jobs and point at primitive tokens that name values —

"background": { "$value": "{neutral.50}",  "$type": "color" },
"accent":     { "$value": "{brand.600}",   "$type": "color" }

background → neutral-50 and accent → brand-600 are decisions in their own right, separate from what neutral-50 and brand-600 happen to store. “The accent is the brand color” and “the brand color is this blue” can now change independently: a rebrand edits the second statement, a theme re-points the first, and neither touches the components that consume accent.

How do tokens reach code and design tools?

By export. The tokens file itself is deliberately neutral — JSON that belongs to no single tool — and each consumer receives a generated view of it: custom properties for stylesheets, a theme block for Tailwind, Figma Variables for the design file, key-value resources for native platforms. One source, several renderings, the same names everywhere.

Scale Composer works this way end to end: it derives type, spacing and color ramps plus light- and dark-theme semantic roles from one shared scale, and everything it derives leaves as one DTCG tokens file alongside CSS custom properties, a Tailwind v4 @theme block and Figma Variables, hex carried next to the OKLCH values. Open a generated token system in Scale Composer — the file’s sections on one side, and the same names rendered as CSS, Tailwind and Figma exports beside them.

What does the same button look like with and without tokens?

Style-guide-speak first, the way a PDF would put it:

Primary buttons use the brand blue (#2563EB) as their background, with white text.

Token-speak second:

{
  "color":    { "brand": { "600": { "$value": "#2563eb", "$type": "color" } } },
  "semantic": { "accent": { "$value": "{color.brand.600}", "$type": "color" } },
  "button":   { "background": { "$value": "{semantic.accent}", "$type": "color" } }
}

The content is the same, but the token version carries a trace. Ask what the button’s background is and the file answers in hops: button.background → semantic.accent → brand-600 → #2563eb, which is oklch(0.546 0.215 262.9). Each hop is a decision that can change without disturbing the others — re-point accent for a theme, change what brand-600 stores for a rebrand, detach button.background from accent the day the button genuinely needs to stop following it. The PDF sentence holds one fused decision; the trace holds three separable ones.

Where does the term come from?

Two sentences of history: Salesforce coined “design tokens” around 2014, when its design system had to serve web and native platforms from one set of decisions, and built tooling that translated a single token file into each platform’s format. The term outgrew its origin — today the Design Tokens Community Group (designtokens.org) maintains a shared interchange format that design tools and build pipelines have broadly converged on.

Why did the industry converge on design tokens?

Because of drift: design files and shipped code disagreeing about values that are supposed to be identical. Drift has no process solution — asking designers and developers to keep two lists in sync treats a structural problem as a discipline problem, and the lists diverge again at the next deadline. The intuitive version is nearly arithmetic: two copies of anything, maintained by different hands, drift apart; more copies drift faster. Tokens change the shape of the problem so there is nothing left to synchronize — one copy is the source, and the other N−1 are generated views of it. The design file and the stylesheet agree because neither is maintained by hand; both are read from the same decisions.

What are design tokens not?

Not just variables. Variables are the storage mechanism; tokens are variables plus the discipline — role-based names, layers, references — that makes the stored decisions navigable. A --blue can hold anything its author typed; a token system is structured so a reader can tell what a value is for and what depends on it.

Not just for big teams. Multi-platform organizations named the problem first, but a single designer rebranding a small site faces the same drift at smaller scale: the same values duplicated across a design file and a stylesheet, diverging quietly.

Not a Figma feature. Figma Variables are one consumer of tokens — a place a generated view lands — not the place tokens are defined. Treating any single consumer as the source puts the decisions back inside one tool, which is the situation tokens exist to end.

Trace one decision end to end

A definition settles once you have followed a real chain of hops yourself. Open the semantic roles in Scale Composer and trace one token — pick accent, follow it down to the primitive step it references and the value stored there, then change the seed and watch the decision above hold steady while the answer beneath it changes.