Design Tokens Are Finally Boring, and That Is the Point

Two years ago, design tokens were a conference topic. This year they are a line in our statements of work. We have now built token architectures into three client engagements in 2022, the W3C Design Tokens Community Group has a draft format spec that tooling vendors are actually implementing, and Figma's variables-shaped future feels like a matter of when, not if. Tokens have become boring infrastructure, which is exactly what good infrastructure should be.

But "everyone is doing tokens" has produced a lot of token systems that are just renamed Sass variables. Here is where we draw the lines.

A token is a decision, not a value

The mistake we see constantly: teams export every color in the mockups into a JSON file and declare victory. Four hundred tokens, zero architecture. The result is a system that is harder to use than raw hex codes, because now there are two things to remember instead of one.

A token earns its place by encoding a decision. Not "this blue exists" but "this is the color of interactive text." We structure every system in three layers:

• Primitives: the raw palette, type scale, spacing ramp. Named descriptively, never used directly in product code.
• Semantic tokens: color.text.interactive, space.inset.card. This is where meaning lives, and this is the only layer designers and engineers should touch daily.
• Component tokens: sparingly, only where a component genuinely needs to vary independently, like button.radius.

When the Møller team asked for a "warmer" feel across their digital products this spring, the change touched eleven primitive values and shipped everywhere in a day. That is the entire business case in one sentence.

Naming is the actual work

Every token project spends more time on naming than anyone budgets. This is not a failure of process. Naming is the process. A token name is an API contract between design and engineering, and like all API contracts, its cost is paid by every future person who has to guess what it means.

Our rules, learned the hard way: name by role, never by appearance. The token called gray-500 becomes a lie the day the brand refreshes. Prefer long and unambiguous over short and clever. And write the forbidden list down: which layer product teams may not reach into, what happens in code review when they do.

Tooling matters less than governance

Style Dictionary, Tokens Studio, hand-rolled build scripts: we have shipped all three, and honestly, the tooling choice has never determined whether a token system succeeded. Governance has. The systems that thrive have a named owner, a change process lighter than a committee but heavier than a Slack message, and a release cadence engineers can plan around.

The systems that die all die the same death: someone needed a slightly different value, nobody answered within a day, and they hardcoded it. Multiply by fifty and the system is decorative.

Why this matters more right now

There is a reason tokens went mainstream in 2022 specifically. Teams are being asked to ship across more surfaces than ever, web, iOS, Android, email, embedded commerce, with flat or shrinking headcount. Tokens are how a design decision made once propagates everywhere without a designer standing guard over each surface.

That is not a craft compromise. It is craft applied at the level of the system instead of the artifact. The kerning still matters. Tokens are how you afford to keep caring about it.