Motion Is the Last Under-Tokenized Layer
Nov 2026Productive versus expressive motion, choreography rules that actually get written down, and why generated UI makes them mandatory.
Why this is on my mind
We tokenize color, type, and spacing without much argument. Motion is usually the exception: it lives in individual components, tuned by feel, and nobody can say what the product's easing "is." If an AI is going to assemble screens, that gap becomes a problem.
What's true right now
Design systems are writing motion down. The Aura design system documented by Cognite describes two roles for animation: productive motion as the default, with expressive motion earned for moments with narrative weight. It warns that overusing expressive motion trains users to ignore it, notes that exits are often slightly faster than entrances, and defines duration tokens (up to about 200 ms for small components, around 500 ms for large surfaces) and stagger tokens of roughly 100 to 133 ms. It even tells engineers not to hardcode raw cubic-bezier values in product code.
Big systems tokenize it too. A third-party skill summarizing Material Design 3 describes motion as shared-axis transitions, container transforms, and three easing families, with named duration tokens from 50 ms for ripples upward. Treat it as a secondary summary, but it matches how the system presents motion as tokens.
Choreography is about order. A motion-system skill frames movement as a token layer with choreography rules for groups, stagger, and direction, and requires reduced-motion behavior that still preserves status information. A separate animation-systems guide gives a plain principle: the primary element moves first and secondary elements follow with a small stagger, so motion establishes a reading order.
Feel lives in details. Jakub Krehel's polish rules include a press state that scales the element slightly (for example to 0.96) with a transition, listed alongside interruptible animations and enter/exit recipes. Emil Kowalski's Sonner animates entirely with percentage-based vertical translations so a toast always moves by its own height, whatever its size.
A small vocabulary, sketched
Illustrative: my own sketch, not a sourced fact.
Names before numbers. A closed set could begin with a few durations, a few easings and one stagger, each with a plain name. Components and generated screens would reference the names only. If someone wants to change how the product feels, they change one value in one place, and everything follows. The first pass can be rough. What matters is that there is a list at all, because a list can be edited and a pile of habits cannot.
Rules for when, not just what. The words matter less than the guidance on using them. Which one is for small components, which one is for large surfaces, and when does a moment earn expressive motion at all? Without that, the model has a vocabulary but no grammar, and will still produce screens that move oddly. Writing the grammar down also helps the humans. A designer reviewing generated output has something concrete to check it against, instead of a feeling that it looks off.
Where a closed set can fail
My opinion, based on the tradeoffs above.
Too small, and it gets bypassed. A vocabulary that cannot express a real product moment will be worked around, and every workaround is a new undocumented value. That is the failure I described in what would change my mind, and the fix is to grow the set deliberately. The answer is not to loosen the rules but to be thoughtful about the set, and to review it as the product grows so it does not drift or bloat.
Consistency can become flat. If everything moves the same way, nothing stands out. This is why the split between productive and expressive motion matters. The closed set should include a small, rarely used expressive tier so that the moments with weight can still feel different. I would keep that tier small and write down what earns it. If every screen finds a reason to use it, the earlier warning about users learning to ignore it comes true.
My hypothesis
This section is my opinion, not a sourced fact.
In a world of generated screens, motion tokens must be a closed set: the model can choose from named durations, easings, and staggers, and cannot invent new ones.
Nobody will hand-animate screens that didn't exist until a user asked for them. If the model is free to write its own timing values, every generated screen will move slightly differently, and the product will feel like it was built by a committee of strangers. If the only allowed values are duration/short, ease-entrance, stagger/default, and a handful more, then the product keeps one physical personality no matter what gets generated.
That puts motion in the same category as color: a policy, not a decoration. And the interesting design work moves up a level, to choosing the small vocabulary and the rules for when to use each word.
How I'd test it
Generate 20 transitions with free-form timing and 20 with the closed token set. Have designers rate consistency blind. I'd expect the closed set to win clearly.
What would change my mind
If product moments need bespoke choreography often enough that the closed set is constantly bypassed, the vocabulary is too small, and the fix is a bigger vocabulary, not an open one.
What I would do first on a real product
My opinion, a sketch of a first step rather than a method I have run.
Inventory what already exists. I would collect every duration and easing already in the product and see how many distinct values there really are. My guess is far more than anyone intended, and the clusters in that list suggest what the first tokens should be. It feels tedious, but it is the cheapest step. Most of the value comes from seeing the real spread of values, which usually surprises everyone on the team.
Merge, name, then restrict. I would fold near-duplicates into a short named list, move components onto it, and only then let a generator near it. Handing a model an unrestricted pile of timings would simply teach it the existing inconsistency, at a much higher speed. Once the list is short and named, the generator has far less room to go wrong, and the review gets simpler too, since there are fewer ways for a screen to differ.
References
- Cognite, Aura Design System: Motion
- Open Skill Index, Material Design 3 skill summary
- Open Design, Motion System skill
- UI Skills, animation-systems
- Open Skill Index, make-interfaces-feel-better by Jakub Krehel
- Emil Kowalski, CSS transforms