Motion Deserves Better Than a Prop
What we lost when animation became a component and time stopped mattering
Motion is the only design medium that exists in time. Every other decision in a design system, colour, type, spacing, elevation, is spatial. It goes in a table, held as a fixed value, compared against another, shipped in a token.
The distinction has direct consequences for how animation gets thought about, documented and owned inside a design system. It may also explain why, after years of increasingly sophisticated motion guidelines from some of the best-resourced design teams in the industry, animated interfaces so often feel technically correct and experientially wrong.
The vocabulary that came first
In 1981 Ollie Johnston and Frank Thomas published The Illusion of Life, setting out the twelve principles Disney animators had been working to since the 1930s. Slow in and slow out. Anticipation. Follow through and overlapping action. Staging. Every one of them is a claim about time, about how long something takes and in what order things happen, but they do not resolve to a number.
The web got its own controls twenty-six years later. On 31 October 2007 Dave Hyatt announced CSS animation on the WebKit blog, and a week later Apple sent a proposal to the W3C, written by Hyatt with Dean Jackson and Chris Marrin, that split the problem in two. Implicit transitions, where a property moves smoothly from one value to another. Defined animations, where a property takes a set of values across an interval.
That split is the one design systems inherited. A transition is a duration and a curve, and both of those are numbers. The twelve principles, however, are not numbers.
What the systems built
Reading several systems' motion documentation in sequence is more instructive than reading any one of them closely. The values matter less than what each one assumes motion is for.
Apple's Human Interface Guidelines treat motion primarily as communication. Animations should convey status, provide feedback, and help users understand spatial relationships. The guidance is principled and restrained, prefer quick and precise animations, use motion to communicate rather than decorate, make motion optional. Apple doesn't prescribe easing curves or duration values. The HIG says why motion matters and leaves how to the product team. This produces a wide range of motion quality across the iOS ecosystem, from the physics of a sheet dismissal to the perfunctory fade that ships by default.
Google Material Design took the opposite approach, and took it early. Motion guidance was in the original spec at launch in June 2014, and the four transition patterns the system is now known for, container transform, shared axis, fade through and fade, followed in February 2020. The documentation specifies easing curves precisely, distinguishing between standard, deceleration, acceleration, and sharp curves, each with a defined cubic-bezier value and a named use case. Duration guidelines are similarly specific, with recommended ranges for elements entering the screen, leaving it, and moving within it. Material's motion system is thorough and internally coherent. It is also, by design, the same across every product that uses it. The easing curve that opens a dropdown is the curve that opens every other dropdown in every Material application. Consistency was the goal and it was achieved.
/* Material Design: four curves, one cubic-bezier each */
--ease-standard: cubic-bezier(0.4, 0.0, 0.2, 1); /* most transitions */
--ease-decelerate: cubic-bezier(0.0, 0.0, 0.2, 1); /* entering the screen */
--ease-accelerate: cubic-bezier(0.4, 0.0, 1.0, 1); /* leaving the screen */
--ease-sharp: cubic-bezier(0.4, 0.0, 0.6, 1); /* return trips */IBM's Carbon Design System went furthest of all. The @carbon/motion package was on npm by November 2018, and motion tokens shipped with Carbon v10 at IBM's Think conference in April 2019, in the same release as the rest of the visual overhaul rather than trailing behind it. Carbon has perhaps the most complete motion documentation of any public design system: two named motion styles (productive and expressive), a non-linear duration scale, custom easing curves stored as tokens, a Motion Generator for calculating duration based on element size, and a philosophical frame that pairs the efficient with the human, drawn from IBM's brand. Productive motion is efficient and quick, designed for task-focused moments. Expressive motion is more visible, reserved for significant transitions. The distinction is useful. It is also the only place in a major system where motion is given two registers to choose between.
// Carbon: two registers, different curves and durations
{
"productive": { "easing": "cubic-bezier(0.2, 0, 0.38, 0.9)", "duration": "150ms" },
"expressive": { "easing": "cubic-bezier(0.4, 0.14, 0.3, 1)", "duration": "400ms" }
}And then there are the systems where motion arrived late or hasn't fully arrived at all. Workday Canvas acknowledges motion in principle but notes it is not currently available as tokens. Shopify Polaris and Atlassian have since built it out, Polaris with duration and easing tokens and Atlassian with a set of semantic motion tokens keyed to intent, but both did so long after their colour, type and spacing scales were settled. A request for motion tokens was opened against polaris-tokens on 19 September 2019, closed in January 2022, and the motion token group didn't appear in the repository until the following April, two and a half years later. Atlassian's remain experimental, released to a limited set of components behind a feature flag, platform-dst-motion-uplift, and still expanding across the system. Motion is reliably the last layer a system gets to, and often the thinnest. This is reasonable prioritisation by teams under real constraints. Motion is hard to specify, harder to implement consistently, and the cost of getting it wrong is often invisible to everyone except the user.
The same element moving the same distance under four systems' motion values at once. Material Design's standard curve over 300 milliseconds; Carbon's productive curve over 150; Carbon's expressive curve over 400; and a spring, which overshoots its target by about 13 per cent and settles after 652 milliseconds. The first three cannot overshoot: a cubic-bezier bounded between nought and one has no way to pass its destination and return.
- one curve, every product, consistency as the goal
- efficient and quick, for task-focused moments
- more visible, reserved for significant transitions
- physics rather than a curve — it can pass the target
The three curves are the values those systems publish, quoted earlier in this essay. Material 3 Expressive replaced fixed curves with springs; the damping and stiffness here are this demo's own, picked so the overshoot is visible at this size.
Reduced motion is on, so nothing runs. The four values are stated above: 300ms, 150ms, 400ms, and a spring that settles at 652ms after passing its target by 13 per cent.
Some systems assume motion is a set of values to be specified and shipped. Others assume it is a set of principles to be interpreted. A few assume it is not worth the cost of systematising at all.
Treating duration like spacing
Motion put into a design system gets the same structure as everything else. Tokens, a duration scale (100ms, 200ms, 300ms, maybe a 400ms for larger transitions), a set of named easing curves (ease-in for exits, ease-out for entrances, ease-in-out for in-place changes), and some principles about when to use each. Documentation gets written and it ships.
/* a typical duration scale, shipped as tokens */
--duration-fast: 100ms;
--duration-base: 200ms;
--duration-slow: 300ms;
--duration-slower: 400ms; /* larger transitions */This structure works for colour. A hex value renders the same on every screen and in every context, so the token holds the whole decision. Motion is not like that. A duration and a curve are settings, and what the user experiences depends on what is moving and why.
A colour token is the colour itself. A motion token is only a setting for something that happens in time.
A 200ms ease-out is precise and reproducible as a value. As an experience, it depends entirely on what is moving, how far, from what visual weight, in response to what user action, in what emotional context. A modal appearing in 200ms ease-out at the start of an onboarding flow feels different from the same values applied to an error state appearing mid-task. While the numbers are identical, the experience is not. A token can't carry that context. It carries the parameter.
/* the same value, two contexts */
.onboarding-modal { transition: transform 200ms var(--ease-out); } /* reads as calm */
.error-toast { transition: transform 200ms var(--ease-out); } /* reads as abrupt */
/* identical parameters, opposite feeling */One duration token and one easing token, applied to two entrances at once: a welcome modal at the start of onboarding, and an error toast during checkout. Both use the same keyframe and the same travel distance, so the only thing that differs between them is the context they arrive into. Currently 200ms, ease-out.
transition: transform 200ms cubic-bezier(0, 0, 0.2, 1);
Reduced motion is on, so both entrances are instant. The tokens above still resolve to 200ms ease-out — they are simply not spent on movement.
Carbon's distinction between productive and expressive motion is an attempt to encode context into the system: different curves and durations for different emotional registers. It is a genuine contribution. But even Carbon's two-mode system is a simplification of the actual range. A notification appearing during a critical workflow is different from a notification appearing on a dashboard. Both might qualify as expressive. They should not necessarily feel the same.
The documentation has tokens, it has principles, it has a Motion Generator, so the problem looks solved. But it is never explores how motion should feel like.
What gets lost in the token
When motion is systematised, three things tend to happen.
Easing curves stop being chosen and start being applied. A designer working outside a design system will often spend real time on an easing curve, adjusting the cubic-bezier in a prototype, watching it over and over, asking whether it feels right. A designer working inside a system reaches for the token. The token is the approved value. Whether it is right for this animation is a separate question, and the system gives no way to ask it.
Duration stops being felt and starts being calculated. Carbon's Motion Generator is an elegant tool, input the element size and travel distance, receive the recommended duration. It is useful. It is also a way of settling duration without ever experiencing it. Consistent is not the same as right. A 247ms duration can be exactly what the formula produces and slightly wrong in context, and the formula can't feel that.
// Carbon: duration derived from how far a thing travels, on a non-linear scale
function duration(distancePx) {
// larger travel takes longer, but sub-linearly, so big moves never drag
return clamp(baseline + rate * Math.pow(distancePx, exponent), min, max)
}
duration(240) // → 247ms, precise and unfeltChoreography disappears almost entirely. Choreography is what happens between animations: the sequencing, the relationship between elements, the way one motion anticipates the next. It is the hardest thing to specify and the most powerful thing motion can do. IBM's documentation mentions choreography. Most systems do not. And because it is hard to put in a token, it tends to get omitted from the system, which means it tends to get omitted from the product.
/* choreography lives between the elements, not inside one token */
.list-item {
animation: rise 320ms var(--ease-decelerate) both;
animation-delay: calc(var(--index) * 40ms); /* the stagger is the effect */
}
@keyframes rise {
from { opacity: 0; transform: translateY(8px); }
to { opacity: 1; transform: none; }
}Six list rows entering with a fixed duration of 320 milliseconds and a fixed decelerate curve. The only variable is the delay between one row and the next, currently 40ms, running top down. The last row settles 520 milliseconds after the first one starts.
duration: 320ms; easing: cubic-bezier(0, 0, 0.2, 1);
animation-delay: calc(var(--index) * 40ms); /* last row settles at 520ms */
a list assembling itself (40ms between rows)
Reduced motion is on, so the rows are already in place. The stagger would have been 40ms between rows, settling the last one 520ms in.
The libraries pushed the same way. Framer acquired Matt Perry's Popmotion in 2018 and released Framer Motion the following year, and it did for React roughly what tokens did for CSS. An animation became a component with props on it, initial and animate and transition, sitting in the same JSX as everything else. It is a good library and the ergonomics are the point. A developer who would once have written keyframes and watched them play now just passes an object.
/* the animation, as a prop */
<motion.div
initial={{ opacity: 0, y: 8 }}
animate={{ opacity: 1, y: 0 }}
transition={{ duration: 0.32, ease: 'easeOut' }}
/>Motion became a prop. Props get filled in.
Duration tokens are better than no duration tokens. A shared easing curve is better than every developer choosing their own. Systematisation guarantees a baseline. The danger is that the baseline is all anyone aims for.
The case for the system
Before motion tokens, most products had no motion philosophy at all. Animations happened because a CSS transition was the easiest thing to add, or because a library shipped with default spring physics, or because a developer remembered reading somewhere that 300ms was a good duration. The results were inconsistent: things moved at different speeds, exits and entrances shared a curve, and some elements animated while others did not, with no logic governing which.
A motion system fixes this. It creates a shared vocabulary, so a designer and an engineer can have a conversation about animation in the same terms. The modal that opens in one part of the product feels related to the modal that opens in another. Reduce motion gets thought about once and implemented everywhere rather than discovered as a gap six months before launch.
iOS 7 shipped in September 2013 with parallax on the home screen, and enough people reported nausea that Apple added a Reduce Motion toggle under Accessibility within weeks. The web took longer. Safari 10.1 shipped `prefers-reduced-motion` in 2017, Firefox followed in 2018 and Chrome in 2019, so it wasn't safe to rely on everywhere until 2020. The browser could animate thirteen years before it could check whether the user wanted it to.
The Workday Canvas documentation, despite having no motion tokens, at least articulates the principle that all animations must have a known purpose and that motion should not get in the way of the user completing their task. That is more than many products have. Carbon gives a team somewhere to start, which is more than a blank stylesheet does.
The real question is what the system is for. Is it a baseline that frees designers to make considered choices within a consistent frame, or a complete answer that makes the considered choice unnecessary?
The space the token cannot reach
The questions of intent is a category of motion decisions that no token system has yet addressed. Parameter cannot answer them.
When does movement read as confidence, and when as caution? When does speed read as efficiency, and when as dismissiveness? When should the interface hold still? These have no cubic-bezier answer. They are questions about what the product is trying to say in time, and answering them takes a view about what the product is trying to say at all.
Motion that works comes from products that settled these questions before they opened the animation tool. Apple's system animations feel inevitable, which comes out of years of attention to the relationship between gesture and response. Linear's transitions are quick and precise, and they say something about who the product thinks its user is, someone who doesn't want to wait. Stripe's motion carries weight and moves at a considered pace, which says this is a tool for serious transactions and nothing here happens casually.
These are position decisions, made before the parameters were set.
This is where the motion system, however good, reaches its limit. A system can encode an existing sensibility. IBM Carbon built its two registers on a brand idea: the productive curves are clipped and efficient, the expressive ones have more give. It works because IBM decided what its motion should feel like, then built the system to match. The tokens are the output of that decision. They cannot stand in for it.
Owning motion
For whoever owns motion in a design system, the documentation is probably not the most important deliverable.
The most important deliverable is a written answer to what the product should feel like in time. Not which easing curves to use. What the motion is trying to say. Whether the product should feel fast or considered, whether transitions should draw attention or recede from it, whether the system should read as responding to the user or anticipating them. Every product has to answer that for itself, and the token system should be the expression of the answer rather than a replacement for it.
Some systems are beginning to move in this direction. IBM Carbon's productive and expressive distinction is a step toward encoding emotional register rather than just technical parameters. Google's Material 3 Expressive, announced on 13 May 2025, treats expressiveness as a legitimate design goal rather than something to be minimised in the name of efficiency, and replaces fixed curves with a spring-based motion physics system. Google put 46 studies and more than 18,000 participants behind it. That is a large amount of research spent establishing that people want interfaces with some character, which is worth sitting with.
The field still treats motion as a consistency problem more than a communication one. Most motion systems aim to make animations feel the same across a product. The larger aim is that animations mean something, that how a thing enters or leaves the screen fits what it is and why it is there. Experienced in time, a product can have a character as considered as its colour or its type. It has to be decided, and decided before the token is set.