Design Tokens Are Not a Design Problem: Shipping a 2026-Ready UI System

The short answer

Design tokens hit 84% adoption in 2026, and the Design Token Community Group (DTCG) shipped its first stable spec. If you're an engineer evaluating a token system for production, here's the hard truth: tokens are not a design problem. They are a runtime contract between your design system and every product surface it touches. The naming conventions, Figma variables, and brand hierarchy debates are table stakes. What separates a system that ships from one that collapses under its own weight is how tokens encode product states, accessibility requirements, and cross-platform behavior.

I've seen teams spend six weeks debating whether to call it color-brand-primary or color-primary-brand while their token pipeline couldn't express a simple high-contrast override. The DTCG spec solves the serialization problem — it gives you a portable JSON format for tokens. It does not solve the harder problem of how tokens behave at runtime. That's an engineering decision, and it's where most systems fail.

Key takeaways

• Tokens are a runtime contract, not a naming exercise — prioritize state resolution over naming conventions
• The DTCG spec solves portability, not behavior — you still need to design how tokens respond to context, user preferences, and accessibility overrides
• 84% adoption means the industry has converged, but adoption without discipline creates technical debt faster than no system at all
• A token system without a clear state model (light, dark, high-contrast, reduced motion, brand variants) is just expensive renaming
• Figma-to-code parity is valuable but secondary — the primary value is runtime consistency across platforms and products
• Evaluate token systems by how they handle failure: what happens when a token is missing, or when a value doesn't resolve?

The real problem: tokens as serialization, not behavior

Most teams approach tokens as a serialization problem: "How do we get colors from Figma into code?" That's the easy part. The DTCG spec gives you a standard JSON structure for token values, aliases, and groups. Export from Figma, import into your codebase, done.

The hard part is what happens next. A token like color.surface.primary doesn't have a single value — it has a value for light mode, another for dark mode, another for high-contrast mode, and potentially more for brand variants or user preferences. The serialization format can express these as groups or aliases, but the runtime engine that resolves the correct value based on context is entirely on you.

This is where the gap between design intent and shipped product widens. Designers define tokens in isolation — a color palette, a spacing scale, a type ramp. Engineers inherit a JSON file and have to build a resolution system that accounts for user preferences, system settings, component state, and accessibility overrides. If the token system doesn't encode these conditions explicitly, engineers will hardcode fallbacks, and the system degrades into inconsistency.

Tradeoffs and when the conventional wisdom breaks

The conventional wisdom says: "Start with a small set of tokens and expand as needed." That's sound advice for a greenfield project. But in practice, most teams adopt tokens into an existing product with years of accumulated styles. The migration path is rarely clean.

Here's where the advice breaks: if you start too small, you create a token system that can't express the real product states. You end up with tokens for light mode only, and every dark mode or high-contrast override is a special case. Those special cases multiply until the token system is just another layer of indirection on top of hardcoded values.

A better approach: define the state model first. List every context your product needs to support — light, dark, high-contrast, reduced motion, brand A, brand B, device type, user role. Then design tokens to express those states. The token count will be higher initially, but the system will survive contact with real product requirements.

How this looks in a shipped product

In a recent project, we shipped a multi-brand SaaS dashboard with a token system that supported four brand variants, light and dark modes, and WCAG AAA contrast overrides. The key decision was encoding brand and contrast as token dimensions, not as separate themes.

Each token resolved through a pipeline: user preference → system setting → brand context → component state. A color.text.primary token in a high-contrast, dark mode, Brand A context resolved to a different hex than the same token in standard contrast, light mode, Brand B. The resolution logic was a pure function — given a context object, return the correct value. No conditional CSS, no theme switching logic in components.

The result: components never needed to know about themes or brands. They consumed tokens by semantic name, and the runtime handled the rest. When we added a new brand variant, we added a token file — zero component changes.

What to evaluate in a token system

When I evaluate a token system for production, I ask three questions:

1. State resolution: Can the system express all the contexts my product needs? Not just light/dark, but high-contrast, reduced motion, brand variants, user preferences, and component states (hover, active, disabled, error).

2. Failure behavior: What happens when a token is missing? Does the system throw an error, fall back to a default, or silently return undefined? Silent failures create bugs that are hard to trace.

3. Tooling integration: Does the token pipeline integrate with your existing toolchain? Can designers export tokens from Figma in a format your runtime can consume? Is there a validation step that catches missing or invalid tokens before they reach production?

If a system can't answer these clearly, it's not ready for production.

Closing: ship the contract, not the catalog

Design tokens are not a catalog of colors and spacing values. They are a contract between design intent and shipped product. The DTCG spec gives us a common language for that contract, but the runtime behavior is where the value lives.

If you're building or adopting a token system in 2026, start with the state model. Define every context your product needs to support. Design tokens to express those contexts. Build a resolution engine that is a pure function of context. Then let components consume tokens by semantic name and never think about themes again.

The teams that do this will ship consistent, accessible, multi-brand products with less code and fewer bugs. The teams that treat tokens as a design problem will have a beautifully organized JSON file and a product that still doesn't work in dark mode.