Design Tokens Explained: The Bridge Between Figma and Your Codebase

Every product team has had this argument. The designer says the blue is wrong. The developer insists it's the blue from the mockup. Both are right: the designer updated the palette three weeks ago, the developer copied the hex from a screen designed five weeks ago, and there are now four slightly different blues in production. Nobody made a mistake — the system made the mistake, because there was no system. Design tokens are the fix, and they're much simpler than the term sounds.

What a design token actually is

A token is a named, reusable design decision: a color, a spacing step, a font size, a shadow, stored as data with a meaningful name.

color.action.primary   = #4A47E0
space.md               = 16px
radius.card            = 8px
font.size.body         = 16px

The insight isn't the values — it's the names. #4A47E0 is a fact; color.action.primary is a decision. When the design language changes, the decision keeps its name and changes its value, and everything referencing the name updates together. Hardcoded hex values are decisions with amnesia: once #4A47E0 is pasted into forty files, nobody knows which instances meant "the action color" and which coincidentally matched.

One nuance that pays off later: name tokens by role, not appearance. A token called color.indigo breaks semantically the day the brand shifts to teal; color.action.primary survives any rebrand — and it's what makes dark mode a value-swap instead of a rewrite.

How the same token flows from Figma to code

The modern pipeline, end to end:

1. Designers define tokens in Figma as Variables (Figma's native tokens) — the palette, spacing scale, and type scale exist once, and every mockup references them.
2. Tokens export as data — JSON, typically via Figma's API or a tokens plugin. This file is the contract between design and engineering.
3. A build step transforms the data into platform formats — tools like Style Dictionary emit CSS custom properties, a Tailwind config, iOS/Android constants, whatever each platform consumes.
4. Components reference tokens, never raw values.

The payoff scenario: the designer adjusts color.action.primary in Figma, the export regenerates, and the next deploy updates every button on every platform. The "wrong blue" argument is structurally over — there is exactly one blue, and both sides read it from the same source.

Teams without the pipeline still benefit from the discipline: even a hand-maintained token file that designers and developers both treat as the source of truth kills most of the drift. The tooling automates the agreement; it can't replace it.

Where to start: colors and spacing first

The classic failure is trying to tokenize everything in week one — forty typography tokens, elevation scales, motion curves — and drowning. Start where drift hurts most:

• Colors, because they drift most visibly (the four blues problem), and
• Spacing, because a fixed scale (4/8/12/16/24/32…) ends the 13px-vs-15px padding lottery and makes layouts feel coherent almost overnight.

Get those two adopted — actually adopted, meaning code review rejects raw values — then expand to type, radii, and shadows. A small token set that's enforced beats a complete one that's advisory, which is the same adoption economics that decide whether design systems live or die.

A concrete example: one swatch, end to end

Designer creates a Figma variable action/primary = #4A47E0. The export produces:

{ "color": { "action": { "primary": { "value": "#4A47E0" } } } }

The build step emits a CSS custom property:

:root {
  --color-action-primary: #4a47e0;
}

And components spend the token by name:

.button-primary {
  background: var(--color-action-primary);
}
 
.link {
  color: var(--color-action-primary);
}

That's the whole mechanism. When the value changes upstream, the button and the link can't disagree — they're not two opinions about a color, they're two references to one decision. (This site runs on exactly this pattern: a paper/ink palette plus five functional accent colors, defined once, referenced everywhere.)

Tokens are the rare practice that's simultaneously a designer tool, a developer tool, and a peace treaty. Start with colors and spacing this sprint; the pipeline can come later. The agreement is the product — the tooling just keeps it honest.