Design Tokens Are Solved. Adoption Is Not.

Design token adoption went from 56% of teams to 84% in a single year. The W3C Design Tokens Community Group shipped its first stable format module in October 2025, backed by Adobe, Google, Meta, Figma and around twenty other organisations. Tokens are no longer a position you argue for. They are the default.

Which means the interesting question has moved. It is no longer whether to use tokens. It is why so many teams now have tokens and still have inconsistent products.

Tokens do not create consistency. Adoption does.

A token file is a claim about what the colours and spacings are. It becomes true only when the interfaces actually reference it.

The failure is quiet and it looks like this. The system publishes a token set. Three teams adopt it properly. A fourth team needs a shade that is not in the set, hardcodes a hex value under deadline, and ships. Six months later there are forty hardcoded values, two of which have quietly become de facto brand colours, and nobody can rename a token without breaking something they cannot find.

Nothing failed loudly. The system is still there, still documented, still technically adopted. The product drifted anyway.

This is why adoption is the metric that matters and why it belongs in the baseline rather than the rollout plan. If teams route around the shared components, the ROI model breaks even when the system itself is well built.

The numbers are good, when adoption holds

The published figures are consistent enough to plan against. Engineering teams working from established component libraries show efficiency gains in the 31 to 47% range. Enterprises with mature systems report cost reductions around 40 to 50% and time to market improvements above 20%.

Read those as conditional. They are what a system returns when people use it. A system nobody uses returns a maintenance cost and a documentation site.

Three layers, and why the middle one earns its keep

The structure that survives contact with a real product is three layers.

Primitives are raw values with no opinion. purple-600, space-4. They are a palette, not a decision.

Semantic tokens name the intent. color-surface-raised, color-text-critical, space-inset-card. This is the layer that lets you change a decision once. It is also the layer teams skip, because it feels like indirection for its own sake, and skipping it is what makes a rebrand or a dark mode into a six-month project rather than a week.

Component tokens bind the semantic layer to a specific part, button-primary-background. Useful for genuine per-component exceptions, dangerous as a habit, because a system where every component has its own token set is a system with no shared decisions at all.

If you get one thing right, get the semantic layer right. It is where the leverage is.

Governance moved from approval to detection

The traditional model was a review board. Somebody proposes a component, the board approves it, the component enters the system. It works while the organisation is small and it becomes a queue the moment it is not, and a queue is exactly what teams route around.

The model that scales in 2026 is detection. Enforcement moves into the pipeline: linting designs and code against the token set, flagging hardcoded values in review, catching visual regressions automatically, and surfacing snowflake components before they multiply. You stop trying to prevent drift at the gate and start catching it within a day of it happening.

This changes what a design system team does. Less approving, more instrumenting. The system becomes machine-readable documentation plus automated checks plus named owners who are accountable for drift, rather than a group of people whose calendar is the bottleneck.

Pick the governance model for the size you are

Centralised, one team owns everything, is right early. It is fast, coherent, and it stops being right the moment demand exceeds that team's capacity, at which point it converts into a backlog and the product teams start building their own.

Federated, a core team owns the foundations while product teams contribute components under a contract, is where most mature organisations land. It needs real investment in contribution tooling and review, and it is the only model we have seen hold at scale.

Community-driven, anyone contributes with light coordination, works in engineering-heavy cultures with strong conventions and fails everywhere else.

The mistake is not picking the wrong one. It is picking one and never revisiting it, because the right answer changes as the organisation grows and the symptoms of the wrong answer, a growing queue or growing drift, are visible long before anyone acts on them.

What we would put on the dashboard

Percentage of UI built from system components, by team. Count of hardcoded values outside the token set, trending. Number of components that exist in the codebase but not in the system. Median time from a contribution being opened to it being merged, because that number predicts whether people will contribute again. And time to ship a standard screen, before and after, because that is the one an executive sponsor understands.

Tokens were the easy part, and they are done. The work now is adoption, semantics, and catching drift the week it happens rather than the year it compounds.

We build and rescue design systems for organisations where consistency is a compliance requirement, not a preference. If yours has stalled, we should talk.