Motion is a teaching tool. It tells users what happened, where they are, and what they can do next — without adding a single word to the interface. Use these guidelines to make motion that informs, never to entertain.
A static interface asks the user to do extra work. Did the menu actually open? Did the system register my click? Where did that panel go when I closed it? Motion answers those questions before the user has to ask them. It is not decoration — it is how the interface stays honest about its own state.
But motion is also the easiest thing to over-do. A page that springs, bounces, and shimmers feels alive in the design mock and exhausting in real use. The bar we hold motion to in this system is simple: unobtrusive, brief, and subtle. If you cannot explain in one sentence what an animation is teaching the user, take it out.
Every animation in our products should serve exactly one of these. If you cannot pick one, the animation is not earning its place.
Motion that confirms the system recognized the user's action. Without it, users wonder whether the click registered. A button that briefly compresses on press, a toast that slides in after a save, a chevron that rotates on accordion open — each one closes the loop the user just opened.
Motion that communicates a transition between modes or values — especially when the change is hard to perceive at a glance. A numeric value counting up, an edit icon morphing into a save icon, a row marking itself complete. Same element, new state, the eye keeps track.
Motion that helps users keep their bearings in an information hierarchy. A panel sliding in from the right, a modal scaling up from the trigger, a drawer pushing content aside — each shows the user where they came from and where they can return.
Motion that hints at what the user can do — a list item gently pulsing to suggest it's swipeable, a card peeking over a fold to suggest scroll. Use sparingly; signifiers degrade fast when the interface uses them everywhere.
Six rules to apply when designing motion. Hold every animation to them; the rule that would reject it usually wins.
Motion should slow into and out of its endpoints, not start and stop at constant speed. Linear motion feels mechanical because nothing in the physical world moves that way. Use motion.easing.default for general transitions; reach for motion.easing.enter and motion.easing.exit when an element is appearing or disappearing — they're tuned to feel right for each direction.
When multiple elements appear at once — list items, cards in a grid, fields in a form — animate them in a quick succession rather than all together. The eye follows the last element to settle, so a staggered sequence subtly directs attention. Keep the offset small: 40 to 80ms between siblings is usually right. More than ten elements? Stop staggering and fade the whole group.
When an element changes state, morph it into its new form rather than instant-swap. A submit button that smoothly stretches into a progress bar and resolves to a checkmark teaches the user that all three states belong to the same action. Two separate elements popping in and out teach nothing.
When elements stack — modals over content, popovers over panels — use opacity, blur, or scrim to make the relationship unambiguous. Background content should clearly recede; foreground should clearly own the user's attention. The animation that opens the overlay is also the animation that explains the hierarchy.
The thing the user clicked should appear connected to the thing that responds. A panel that opens from the menu icon should visibly originate from that icon, not from a random screen edge. Child elements move with their parent, and origins are honored.
Motion that takes longer than 500ms is no longer motion — it's a wait. If a transition feels slow, it probably is. The default should be motion.duration.normal (200ms); reach for slower tokens only when the transition covers a large spatial change or carries critical information.
All motion in our products uses these tokens. Never hardcode a duration in milliseconds or an easing curve in cubic-bezier(...). The tokens are tuned to feel coherent across the product, so two engineers building two features end up with motion that visually agrees.
| Token | Value | When to use | Demo |
|---|---|---|---|
motion.duration.instant | 0ms | Reduced-motion fallback. Effectively disables the transition while preserving the property change. | |
motion.duration.fast | 100ms | Hover states, focus rings, button press feedback, micro-interactions on a single element. | |
motion.duration.normal | 200ms | Default for nearly everything. Tab switches, accordion expand/collapse, toast in/out, value changes. | |
motion.duration.slow | 300ms | Page-level transitions, modal open/close, drawer slide, larger spatial shifts. | |
motion.duration.slower | 500ms | Complex multi-step animations or signifier nudges. Use sparingly — anything longer is a wait, not motion. |
Easing demos run at motion.duration.slower (500ms) so the shape of each curve is visible. In production, easing is usually paired with a faster duration.
| Token | Curve | When to use | Demo |
|---|---|---|---|
motion.easing.default | General-purpose. The right answer 80% of the time. | ||
motion.easing.enter | Elements appearing — fast at the start, eases into rest. Feels like arrival. | ||
motion.easing.exit | Elements leaving — eases out of rest, fast at the end. Feels like departure. | ||
motion.easing.spring | Playful overshoot. Use for FABs, success confirmations, signifier nudges — never for routine state changes. |
| Situation | Duration | Easing |
|---|---|---|
| Hover state on a button or link | motion.duration.fast | motion.easing.default |
| Tab or accordion toggle | motion.duration.normal | motion.easing.default |
| Toast or banner appearing | motion.duration.normal | motion.easing.enter |
| Toast or banner dismissing | motion.duration.normal | motion.easing.exit |
| Modal or dialog opening | motion.duration.slow | motion.easing.enter |
| Modal or dialog closing | motion.duration.slow | motion.easing.exit |
| Drawer or side panel sliding in | motion.duration.slow | motion.easing.enter |
| FAB expanding to action set | motion.duration.slow | motion.easing.spring |
| Numeric value counting up | motion.duration.slow | motion.easing.default |
| Loading skeleton shimmer (looped) | motion.duration.slower | motion.easing.default |
The most important rule on this page: always respect prefers-reduced-motion. A non-trivial slice of users — people with vestibular disorders, attention sensitivities, or simply low tolerance for movement on screen — has explicitly asked their device to hold the animation. The system must honor that. WCAG 2.3.3 (Animation from Interactions, Level AAA) is the baseline expectation, not an aspiration.
Wrap every animation in a media query that disables motion when the user has set prefers-reduced-motion: reduce. This pattern already lives in the base styles — component authors don’t need to repeat it, but they do need to ensure custom animations use transition or animation properties (which the query covers), not requestAnimationFrame loops or JS-driven motion (which it does not).
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: 0ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0ms !important;
scroll-behavior: auto !important;
}
}For JS-driven motion, check the user preference explicitly:
const prefersReducedMotion =
typeof window !== 'undefined' &&
window.matchMedia('(prefers-reduced-motion: reduce)').matches;
if (prefersReducedMotion) {
// Skip the animation; jump to end state.
} else {
// Run the animation.
}Reduced motion is not “no feedback.” A button still needs to confirm it was clicked; an error still needs to surface. The right substitution depends on the purpose:
Six paired examples grounded in real situations. Each pair shows what to ship and what to leave on the cutting-room floor.
transition: background-color
var(--motion-duration-fast)
var(--motion-easing-default);transition: background-color 0.5s ease-in-out;The principles in this page stand on their own — they are written for our context and are not numbered against any external source.