Design Tokens, Explained: A Practical Guide for Designers

You change one line. color.brand.primary moves from a warm orange-red to a cooler one, you hit save, and roughly fourteen hundred places update at once: every primary button, every active link, the focus ring, the dark-mode variant, the iOS build, the email templates, the marketing site. Nobody opens a single screen to repaint it. The new red is just correct everywhere, because none of those screens ever knew the hex code in the first place. They knew the name.

That is the whole idea, and it is less exciting than the tooling industry makes it sound. The common pitch is that design tokens are a technology you adopt. They are not. A design token is a decision you refuse to repeat. The technology is just how the decision travels.

The short version: A design token is a named value that stores a design decision, like color.brand.primary = #e84b63 or space.md = 16px, so that decision lives in one place and every design file and codebase references the name instead of the raw value. Change the token, and everything pointing at it updates. Tokens are what let design and code share a single source of truth.

What are design tokens?

A design token is a named variable that holds a design decision. Instead of writing #e84b63 in forty Figma layers and ninety lines of CSS, you define it once as color.brand.primary and point everything at that name. The name carries the intent. The value can change underneath it without anyone chasing down every usage.

Tokens cover more than color. They store spacing, type sizes, line heights, border radius, shadows, motion durations, breakpoints, and z-index. Anything that is a repeated, meaningful value in your interface is a candidate. The test is simple: if you would want to change it in one move and have it ripple everywhere, it should be a token.

Design tokens vs variables vs hardcoded values

People use "token" and "variable" interchangeably, which blurs a useful distinction. A hardcoded value is the raw number sitting inline. A variable is that value stored once in a tool, usually scoped to that tool. A token is the same idea lifted to a tool-neutral format that both design and code can read, which is what makes it portable.

Figma variables are the most common on-ramp, and most teams are already there. In Supernova's State of Design Tokens 2024 report, 69.8% of respondents said they already use Figma variables and another 19.3% plan to. Variables are a real step forward. They become tokens the moment you export them into a format code can consume, which is where the standard below comes in.

Why design tokens matter (the problem they actually solve)

Design tokens matter because they kill drift. Without them, a design system is a suggestion. Someone eyeballs a gray, someone else grabs a slightly different gray, a third person hardcodes a one-off, and six months later you have nine grays that were all supposed to be the same one. Tokens make the agreed value the path of least resistance, so staying consistent is easier than going rogue.

The second thing they solve is the translation tax between design and code. When a color lives as a name in both worlds, a designer changing color.brand.primary and an engineer reading color.brand.primary are talking about the same thing, with no hex code transcribed by hand in a handoff doc. That is the real win, and it is the same wound I keep writing about: the gap between design and engineering is rarely a tools problem, it is a shared-language problem, which is exactly what I argued in the designer-developer gap is a handoff problem. Tokens give both sides the same vocabulary.

They also slow the quiet accumulation of design debt in large, scalable products. Every untokenized value is a small loan you take out against future consistency, and like all design debt you eventually have to spot, measure, and pay down, it compounds. On the Monety fintech platform, which ran to hundreds of screens across loan flows, the difference between a tokenized palette and a loose one was the difference between a brand tweak taking an afternoon and taking a sprint.

The three tiers of design tokens

The structure that scales is three tiers, and getting this right is more important than any tool choice.

Primitive (or global) tokens are the raw palette. color.red.500 = #e84b63, size.4 = 16px. These are just the values you have, named but not yet assigned any meaning. They describe what something is, never where it is used.

Semantic (or alias) tokens are where the real work happens. color.action.primary points at color.red.500. color.background.surface points at some near-black. Now the name says what the value is for, not what it looks like. This layer is why 85% of teams in the Supernova survey report using aliases: it means you can repoint color.action.primary to a different primitive during a rebrand without touching a single component. The components asked for "the primary action color," and they still get it.

Component tokens are the most specific, optional tier: button.primary.background points at color.action.primary. Small teams can skip this one. Large systems lean on it because it lets one component change without disturbing the semantic layer everyone else shares.

If you only build one tier well, build the semantic one. Primitives without semantics are just a palette with extra steps.

How do design tokens work across design and code?

Tokens work across design and code through a shared file, usually JSON, that both sides sync from. The modern pipeline looks like this: you author tokens in Figma variables or a tokens plugin, export them to a tokens file, and a build tool like Style Dictionary or Terrazzo transforms that one file into whatever each platform needs, CSS custom properties for web, Swift for iOS, XML for Android.

The weak link today is still manual syncing. In the same Supernova survey, 44.4% of teams said their design-to-code flow is still manual, versus 31.4% automated. If you are copying values by hand between Figma and a stylesheet, you do not yet have tokens, you have variables that happen to share names. The goal is one source, many outputs, generated.

What the new W3C design tokens standard changes

For years the biggest problem with tokens was that every tool spoke its own dialect, so moving between them meant rewriting. That changed on October 28, 2025, when the Design Tokens Community Group published the first stable version of the Design Tokens specification, numbered 2025.10. It is a vendor-neutral format for sharing design decisions, built by more than twenty editors and authors, with support or active implementation across Figma, Sketch, Framer, Penpot, Supernova, zeroheight, and others, and reference implementations in Style Dictionary, Tokens Studio, and Terrazzo.

The practical effect, as of October 2026, is that a tokens file is becoming portable in a way it was not two years ago. The spec covers modern color spaces, token relationships and aliasing, theming and multi-brand support, and cross-platform consistency. Co-chair Kaelig Deloumeau-Prigent framed it plainly: the specification "unlocks interoperability across design tools and code." For anyone deciding whether to invest in tokens now, a stable open standard is the signal that the format is safe to build on.

How to start with design tokens (without boiling the ocean)

Start with color and spacing, the two that drift fastest. Pull your existing palette into primitive tokens, then build a thin semantic layer on top, maybe ten to fifteen names that describe real uses: primary action, surface, text, border, danger. Wire your most-used components to the semantic names. Ship that. Do not model every shadow and motion curve on day one. The point of tokens is leverage, and you get most of the leverage from the first small, honest layer.

Then make the tokenized path the easy one. If grabbing the right color from the shared library takes two clicks and hardcoding takes ten seconds, people will hardcode. The system only holds when the correct choice is also the convenient one.

Key takeaways

• A design token is a named value that stores a design decision once, so design and code reference the name instead of the raw value.

• Three tiers scale: primitive (raw values), semantic (named by purpose), component (named by use). The semantic tier does the heavy lifting.

• Figma variables are the common on-ramp (69.8% adoption in Supernova's 2024 survey) and become true tokens when exported to a shared, code-readable format.

• The W3C Design Tokens spec reached its first stable version (2025.10) on October 28, 2025, making tokens portable across tools for the first time.

• Start small: color and spacing, a thin semantic layer, your top components. Make the tokenized path the convenient one.

FAQ