Design tokens beyond color: behavior and context in 2026

A behavior token is a design token that encodes how an interface acts over time rather than how it looks at rest: how long a transition runs, which easing curve it follows, how long it waits before starting. A context token is the same idea on the other axis, the mode that decides which values apply when a component lands in dark theme, in a denser table, or under a second brand. The stable Design Tokens Community Group format defines 13 token types. One of them is color.

Most systems stop at three: color, dimension, typography. That describes a screen standing still. It says nothing about what happens between two screens, and nothing about what changes when the same button ships into a compact layout or in front of someone whose operating system has been told to stop moving things. Those two gaps are where a design system goes back to hardcoded values, one component at a time.

The short version

• Seven primitive types. color, dimension, fontFamily, fontWeight, duration, cubicBezier, number.
• Six composite types. strokeStyle, border, transition, shadow, gradient, typography.
• Behavior lives in three of them. duration, cubicBezier, and the transition composite that references both.
• Context is not a type at all. It is the mode layer that decides which value a token resolves to: theme, brand, density, reduced motion.
• The timing is tokenizable. The choreography is not. The spec says so itself, and that limit shapes how you document motion.

What the 2025.10 release actually standardised

The Design Tokens Community Group published version 2025.10 on 28 October 2025, its first stable specification after years of drafts. More than 20 editors and authors worked on it, with contributors from Adobe, Google, Microsoft, Figma, Salesforce, Shopify, Penpot and others. Reference implementations already exist in Style Dictionary, Tokens Studio and Terrazzo.

Two details in that release matter if you care about behavior.

Duration is no longer a string. Earlier drafts accepted "100ms" and left every tool to parse it. The stable format requires an object with a numeric value and a unit of either ms or s.

{
  "duration": {
    "quick":  { "$type": "duration", "$value": { "value": 100, "unit": "ms" } },
    "settle": { "$type": "duration", "$value": { "value": 1.5, "unit": "s" } }
  }
}

Easing is an array of four numbers, not a CSS function. The cubicBezier type holds [P1x, P1y, P2x, P2y]. The x coordinates are restricted to the range 0 to 1, the y coordinates are unbounded, which is exactly what lets you write an overshoot curve.

{
  "easing": {
    "emphasized": { "$type": "cubicBezier", "$value": [0.2, 0, 0, 1] }
  }
}

The transition composite type ties them together. It takes a duration, a delay and a timingFunction, and each one can hold a literal value or a reference to another token. That reference is the whole point: change duration.quick once and every transition built on it moves with it.

{
  "transition": {
    "emphasis": {
      "$type": "transition",
      "$value": {
        "duration": "{duration.quick}",
        "delay": { "value": 0, "unit": "ms" },
        "timingFunction": "{easing.emphasized}"
      }
    }
  }
}

Why motion belongs in the token layer

Look at a system that already did this. Material Design 3 publishes its motion as tokens: four duration families, short, medium, long and extra long, with four steps each, running from 50ms up to 1000ms, plus two easing sets, standard and emphasized. Emphasized easing is cubic-bezier(0.2, 0, 0, 1).

That is around twenty named decisions, made once, by people who tested them against real components. The alternative is what most product codebases actually contain: 250ms in one component, 300ms in the next, 0.2s in a third because someone was writing seconds that afternoon. Nobody decided that. It accumulated.

Once a duration is a token, three things get easier. You can audit it, because a lint rule or a grep for raw ms values in component CSS returns a number you can track. You can change it globally, so "the app feels sluggish" has one place to go instead of forty. And a designer and an engineer arguing about speed argue about a named step rather than an adjective.

The generated output is unremarkable, which is the point.

:root {
  --duration-quick: 100ms;
  --easing-emphasized: cubic-bezier(0.2, 0, 0, 1);
  --transition-emphasis: 100ms cubic-bezier(0.2, 0, 0, 1);
}

What a transition token still cannot say

Here is the limit, and it is written into the specification itself. The transition section carries an open issue asking whether the parameters are useful on their own, given that they do not let you specify which property is being animated or what the start and end states are.

So a transition token says: 200 milliseconds, this curve, no delay. It does not say: opacity plus an 8px vertical offset, on the panel entering from the right, staggered 40ms per row. That choreography stays in component code. Token the timing, document the choreography, and stop expecting the token file to carry a motion spec. Teams that ignore this end up inventing token names like transition-modal-enter-stagger, which is a component decision wearing a token costume.

Context: modes, density, and the second brand

The 2025.10 release added theming and multi-brand support so that light and dark modes, accessibility variants and brand themes live in one file structure instead of duplicated files. That is the format side. The tooling side has its own shape.

In Figma, the equivalent is modes on a variable collection, where each mode stores one value per variable and the number of modes you get per collection depends on your plan. The trap is combinatorics. Modes inside a collection are flat and independent, so brand times theme times density is a multiplication, not a stack. Three brands, two themes and two densities is twelve columns to keep honest, and nobody keeps twelve columns honest by hand.

Two rules keep it survivable. Put each dimension in its own collection, so brand, theme and density stay separable instead of collapsing into one grid. And refuse to add a dimension you cannot name a consumer for. Density is a good example of a dimension worth having: a data table row at 44px comfortable and 32px compact is one dimension token with two mode values, and it removes a whole class of one-off spacing overrides.

Reduced motion is a context, and it wins over the others

prefers-reduced-motion reads a system-level accessibility setting the user has already chosen, on macOS, Windows, iOS, Android or Linux. MDN describes it as a signal that the user wants to minimise non-essential motion. Scaling and panning of large objects can trigger discomfort for people with vestibular disorders, which is why W3C publishes using this query as a WCAG technique.

In a token system this belongs at the root, as an override of the values, not as a second set of durations sprinkled through components.

@media (prefers-reduced-motion: reduce) {
  :root {
    --duration-quick: 0.01ms;
    --duration-settle: 0.01ms;
  }
}

Use 0.01ms rather than 0. A zero-length transition never fires transitionend, and any JavaScript waiting on that event will hang. Two caveats worth writing into your documentation: reduced motion means less non-essential motion, not no feedback, so a state change still has to be perceivable by some other means, usually color or position. And the setting is opt-in at the OS level, so plenty of people who would benefit from it never turn it on. It is a floor, not a survey.

When to add behavior tokens, and when to skip them

Add them when at least two of these are true: you ship to more than one platform, you maintain more than one brand or theme, more than two people write UI code, or someone has already filed a bug that says the product feels inconsistent. Multi-brand is the strongest trigger. The moment a second brand exists, every hardcoded duration is a merge conflict waiting to happen.

Skip them when you have one product, one engineer and fewer than ten animated states. At that size a block of CSS custom properties in one file is the entire system, and a DTCG pipeline with a build step is overhead you will pay for daily and benefit from never. We have shipped both. The difference is not sophistication, it is how many people have to agree.

Name them for the role, not the value

duration-fast survives. duration-150 becomes a lie the first time someone tunes it to 120ms and does not rename the token, and renaming it means touching every consumer. The same rule that applies to color tiers applies here: primitives can be literal, semantic tokens have to describe intent. A useful test is to read the token name out loud in a code review and ask whether it says what the value is for. duration-quick passes. duration-modal passes. duration-200-b does not.

Keep the scale short. Five or six duration steps cover almost every interface, and every step you add is a decision someone will get wrong at 6pm on a Friday.

Where this sits in the rest of the system

Behavior and context tokens sit on top of the same three-tier structure as everything else, so the naming work comes first: see design token naming conventions for the primitive, semantic and component split. If you are still deciding what a token even is against the tools you already use, design tokens vs CSS variables vs Tailwind covers that ground. For the motion side, the review pass before shipping is in functional UI animation. And the wider build order, where motion and density sit relative to the other categories, is in design system structure.

Sources

• W3C Design Tokens Community Group, Design Tokens specification reaches first stable version
• Design Tokens Format Module, version 2025.10
• Material Design 3, Easing and duration tokens and specs
• MDN Web Docs, prefers-reduced-motion
• W3C WAI, C39: Using the CSS prefers-reduced-motion query to prevent motion
• Figma, Modes for variables
• Style Dictionary, Design Tokens Community Group format