Tokens Are Not Just Colors and Spacing

Color and spacing tokens are the easy, visible part of a token system, and most teams stop there without quite noticing they've stopped. They're easy to justify because they're easy to see: a stakeholder can look at two shades of blue side by side and immediately understand why standardizing them matters. Spacing is nearly as visible - a grid that's slightly off reads as sloppy even to people with no design training. Because these properties are so legible in a static screenshot, they get tokenized first, reviewed most carefully, and treated as if they constitute the whole job of a token system, when they're really just the part that was easiest to notice needed doing.

The properties that are hardest to keep consistent by hand - motion duration, easing curves, elevation, z-index layering, the timing of interaction feedback - rarely get the same treatment, and it's not because they matter less. It's because they're much harder to catch in review. A designer looking at a static comp cannot see that a modal's entrance animation takes 180 milliseconds in one part of the product and 340 in another, because a comp has no time dimension at all. These properties only become visible in motion, live, in the product itself, which means the normal review process - looking at files, comparing screens - structurally cannot catch the inconsistency that's actually there.

The result, and it's a strange one, is a product that looks perfectly consistent in every screenshot and every design review, while feeling subtly wrong to actually use. Colors match. Spacing is crisp. And yet every modal animates in on its own schedule, every hover state eases differently, every loading transition has a personality nobody designed on purpose. Users can rarely articulate what's off - they just sense that the product doesn't quite feel like one coherent thing, without being able to point to the pixel that proves it, because the inconsistency isn't in the pixels. It's in the timing between them.

Consider a product team that has genuinely excellent color and spacing tokens - a mature, well-adopted system by any visual measure - but no motion tokens at all. Every engineer implementing a transition picks a duration and easing curve that feels right to them in that moment: some reach for 200ms and ease-out by habit, others reach for 300ms and ease-in-out, a few just use whatever the animation library defaults to. Multiply that across dozens of components built by dozens of people over several years, and the product ends up with as many distinct motion signatures as it has contributors, none of them wrong exactly, all of them slightly different from each other.

It's fair to ask whether this actually matters as much as color and spacing do, and the honest answer is: it depends what the product is for, but it matters more often than teams assume. A dense internal admin tool can probably survive inconsistent transition timing without much real cost. A consumer product where feel is part of the value proposition - where users are comparing it, even unconsciously, to competitors that do feel coherent - pays for this gap constantly, in a way that's genuinely difficult to trace back to its source in a bug report, because nobody files a ticket that says "this modal's easing curve felt 40 milliseconds off."

Motion and elevation tokens are also, honestly, more work to define well than color tokens are, and that difficulty is a real reason teams avoid them rather than a minor inconvenience. A color palette can largely be derived from brand guidelines that already exist. A motion system requires the team to make actual design decisions about how the product should feel to use - should transitions feel snappy and immediate, or should they feel weighty and considered? Should elevation express hierarchy through shadow depth, through scale, through both? There's no existing brand document that answers these questions, which means someone has to originate the answer rather than translate one that already exists elsewhere.

In practice, a motion token system that works starts small and specific rather than trying to cover everything at once: a defined set of durations - fast, standard, slow, each tied to a millisecond value and a clear rule for when to use which - paired with two or three easing curves mapped to types of movement, entrances feeling different from exits, for instance. Elevation tokens follow a similar shape: a fixed small scale of shadow-and-z-index pairs, each one mapped to a specific kind of surface - a resting card, a hovering menu, a modal above everything else - so that "how high does this feel" becomes a lookup rather than a fresh decision every time a new component gets built.

There's a legitimate edge case worth naming: not every interaction benefits from being forced into a fixed token, and a system that's too rigid here produces its own kind of flatness. A hero animation on a marketing page, a moment of deliberate delight in an onboarding flow - these are often exactly the places where breaking from the standard timing is the right call, the motion equivalent of the exception cases design systems generally need to allow for. The token system's job isn't to eliminate every one-off; it's to make sure the hundreds of ordinary, non-special interactions share a consistent baseline, so the deliberate exceptions actually read as deliberate instead of blending into general inconsistency.

Getting motion and elevation tokenized also changes how engineering and design collaborate on interaction work, in a way that's easy to underestimate going in. Once a duration or easing curve is a named token rather than a number typed into a transition property, it becomes something design and engineering can discuss and adjust together, system-wide, in one place - the same shift that happened with color tokens years earlier now happening a layer deeper. Before that, motion decisions live scattered across thousands of individual lines of CSS or component code, each one essentially invisible to anyone auditing the system's coherence from a design review.

The extra work of getting this layer right pays off exactly where it's hardest to capture in a screenshot, a design review, or a stakeholder presentation: in how coherent the product actually feels to use, over time, across every interaction a person has with it. That's a harder case to make for investment than "our colors don't match," because there's no obvious before-and-after image to show. But it's very often the difference between a product that looks like a system and a product that feels like one - and feel, unlike a color swatch, is the part users actually carry with them after they close the tab.