Somewhere in the history of most design systems there is a turning point. The product has grown beyond what a single person can hold in their head. The codebase has multiple contributors. Marketing has a website, product has an app, and both have started drifting apart without anyone intending it to happen.

Design tokens are often introduced at this moment, and they solve a real problem. But understanding what they actually are, and what they are not, matters more than the syntax.

What a token actually is

A design token is a named value that stores a design decision. That is the whole definition. The color your brand uses for primary actions, expressed not as a hex code buried in a stylesheet but as a named variable that both design tools and codebases can reference.

The name carries meaning. color-action-primary tells you something that #4F46E5 does not. When that value changes, you change it once, in one place, and everything that references it updates. No find and replace across twelve files. No wondering whether you caught them all.

{
  "color-action-primary": "#4F46E5",
  "color-surface-default": "#FFFFFF",
  "spacing-md": "16px",
  "radius-card": "8px",
  "font-body": "Inter, sans-serif"
}

{
  "color-action-primary": "#4F46E5",
  "color-surface-default": "#FFFFFF",
  "spacing-md": "16px",
  "radius-card": "8px",
  "font-body": "Inter, sans-serif"
}

{
  "color-action-primary": "#4F46E5",
  "color-surface-default": "#FFFFFF",
  "spacing-md": "16px",
  "radius-card": "8px",
  "font-body": "Inter, sans-serif"
}

{
  "color-action-primary": "#4F46E5",
  "color-surface-default": "#FFFFFF",
  "spacing-md": "16px",
  "radius-card": "8px",
  "font-body": "Inter, sans-serif"
}

The format is almost secondary to the naming. Good token names are the hard part.

Naming as design work

The temptation when building a token system is to name tokens after their appearance: color-blue-500, spacing-24. These names are easy to create and immediately useless. They describe what the value is, not what it does.

Semantic naming requires more thought up front. color-action-primary, spacing-section-gap, radius-interactive. These names survive a rebrand. They survive a decision to change the primary color from blue to green. The token name stays the same; the value changes.

Teams that invest in good naming end up with a token system that is self-documenting. New contributors can read the tokens and understand the design intent without needing to be told.

Tokens as the bridge between tools

The practical value of tokens comes from their portability. A token defined in a JSON file can be consumed by a Figma plugin to populate design variables, by a CSS preprocessor to generate custom properties, by a mobile codebase to populate platform-specific values. The same source of truth, expressed appropriately for each environment.

This is where the handoff conversation changes. Instead of a designer exporting specs and a developer interpreting them, both sides are working from the same named values. Disagreements about whether a component is using the right shade of gray become answerable with a reference, not a debate.

When tokens help and when they do not

Tokens are most valuable on products with multiple surfaces, multiple contributors, or both. A solo designer building a single website probably does not need a formal token system. The overhead is real and the benefit is limited.

For anything larger, the calculus changes quickly. The time spent naming and organizing tokens pays back with interest the first time a brand update needs to propagate across a product suite, or the first time a new contributor needs to understand the design language without a two-hour onboarding session.

The key is starting simple. A small set of well-named tokens used consistently is worth more than an exhaustive system that becomes a maintenance burden and gets worked around.