Most interface animation gets added at the end of a project, when someone says the prototype "feels flat". So a fade goes here, a bounce goes there, and a few weeks later the product feels slow and nobody can say why.

Motion works much better when it's treated as part of the interface from the start, with a job to do. This guide covers what that job is, how long animations should take, which easing curves to use, and how to design for people who need less motion. None of it requires you to be an animator.

Start with what the motion is for

Before animating anything, ask what it's telling the person using it. If the honest answer is "nothing, it just looks nice", it's decoration, and decoration in a product has a cost: it's time the user spends waiting.

Useful interface motion usually does one of these jobs:

• Shows where something came from or went. A card that expands from a thumbnail, a panel that slides in from the edge it lives on, a deleted item that collapses so the list closes the gap. Motion keeps people oriented.
• Signals a change of state. Loading to loaded, collapsed to expanded, off to on. A short transition makes the change noticeable instead of jarring.
• Confirms an action. A button that responds when pressed, a checkbox that ticks. The user knows the input registered.
• Directs attention. A subtle pulse on a new notification, a field that shakes gently after an invalid entry.

If an animation doesn't do one of those, cut it or shorten it until nobody notices it's gone.

How long should it take?

Interface animations are short. The Nielsen Norman Group's guidance puts most of them in the 100 to 500 millisecond range, with simple feedback around 100 ms and bigger changes, like a modal opening, around 200 to 300 ms. Past about 500 ms, animations start to feel like a drag.

Google's original Material Design guidelines give similar numbers for mobile: around 300 ms for standard transitions, up to about 375 ms for large full-screen changes, and a note that transitions over 400 ms may feel too slow. They also suggest two useful adjustments:

• Entering is a bit slower than leaving. Material's examples use about 225 ms for elements entering and 195 ms for elements leaving. Users need to see what arrives; they don't need to watch things go.
• Size and platform matter. Small elements and desktop interfaces move faster (Material suggests 150 to 200 ms on desktop). Larger surfaces and bigger distances take a little longer.

As a practical starting point:

• Button press, toggle, hover feedback: 100 to 150 ms
• Small element appearing (tooltip, menu): 150 to 250 ms
• Modal, sheet or panel opening: 200 to 300 ms
• Large layout or full-screen transition: 300 to 400 ms

Treat these as defaults, then tune by feel on real devices. If you're unsure, go shorter. Almost nobody complains that an interface feels too responsive.

One related idea often gets mixed in here: the Doherty threshold. It comes from a 1982 IBM paper by Walter J. Doherty and Ahrvind J. Thadani, which argued that productivity rises sharply when a computer responds in under about 400 ms. It's about system response time, not animation length, but the lesson carries over: an animation that delays what the user asked for adds to the wait they feel.

Easing: how motion speeds up and slows down

Things in the physical world don't start and stop instantly, so constant-speed (linear) motion tends to look mechanical in interfaces. Easing curves fix that. The names are confusing, because they describe which end of the motion is smoothed, not what the element is doing:

• Ease-out (decelerate) starts fast and slows to a stop. Use it for elements entering the screen. The fast start feels responsive; the slow finish lets the eye land on the element.
• Ease-in (accelerate) starts slow and speeds up. Use it for elements leaving the screen. It feels like the object is heading off somewhere.
• Ease-in-out (standard) speeds up then slows down. Use it for elements moving from one place to another on screen.
• Linear is best kept for things that genuinely move at constant speed, like an indeterminate progress bar or a spinner.

If you want concrete values, Material Design's original curves are a well-tested set. In CSS terms:

:root {

--ease-standard: cubic-bezier(0.4, 0, 0.2, 1); /* moving on screen */

--ease-decelerate: cubic-bezier(0, 0, 0.2, 1); /* entering */

--ease-accelerate: cubic-bezier(0.4, 0, 1, 1); /* leaving */

}

Figma's prototyping settings let you pick ease-in, ease-out and custom curves, so you can match these in prototypes too.

When not to animate

Some changes are better instant:

• Changes the user expects to be immediate, like sorting a table or switching a theme. Animation here reads as lag.
• Many elements at once. Animating 50 list items individually is slow and visually noisy. Animate the container, or stagger only the first few.
• Repeated actions. A delightful 400 ms transition is charming the first time and irritating the fiftieth. The more often something happens, the shorter and subtler its motion should be.
• Anything that blocks input. If users have to wait for an animation to finish before they can tap again, shorten it or make it interruptible.

Reduced motion is part of the design

For some people, motion isn't just annoying. People with vestibular disorders can experience dizziness, nausea or headaches from large movements like parallax, zooming or sliding full-screen transitions. Others find constant motion distracting enough to lose their place.

All major operating systems have a setting to reduce motion, and browsers expose it to CSS through the prefers-reduced-motion media query. Native platforms offer the same signal to apps.

The relevant accessibility guidance is WCAG success criterion 2.3.3, Animation from Interactions: "Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed." It was added in WCAG 2.1 at level AAA, the highest level, which most laws and procurement rules don't require. Don't let that be the reason you skip it. Related level A criteria (2.2.2 Pause, Stop, Hide, for moving content that starts automatically, and 2.3.1, on flashing content) are part of the baseline most standards reference.

Reduced motion doesn't have to mean no motion. The goal is to remove movement that causes trouble while keeping the information the motion carried:

• Replace slides, zooms and parallax with a simple crossfade.
• Keep small feedback like color changes and opacity.
• Stop auto-playing and looping animations, or offer a pause control.

In CSS, a common pattern is to design the calm version first and add movement only for people who haven't asked for less:

.panel {

transition: opacity 200ms var(--ease-decelerate);

}

@media (prefers-reduced-motion: no-preference) {

.panel {

transition:

opacity 200ms var(--ease-decelerate),

transform 250ms var(--ease-decelerate);

}

}

Then test it: turn on reduce motion in your operating system's accessibility settings and use your product for ten minutes.

Motion in a design system

If your team has a design system, motion belongs in it the same way color and spacing do. A small set of tokens goes a long way:

• Three or four durations, such as fast, medium and slow.
• Three easing curves: standard, entering and leaving.
• Documented patterns: what animation each component uses, what it communicates, and its reduced-motion behavior.

With tokens in place, designers and developers stop debating whether a menu takes 180 or 220 ms, and the product ends up feeling consistent.

Keep it smooth

A few performance habits prevent the stutter that makes motion feel cheap:

• Animate transform and opacity where possible. Browsers can usually handle these without recalculating layout. Animating width, height, top or left forces much more work.
• Test on modest hardware. A transition that's smooth on a new laptop may stutter on an older phone, and plenty of your users have older phones.
• Prefer built-in tools first. CSS transitions cover most interface motion. Reach for animation libraries when you need gestures, physics or complex sequencing.

A motion audit you can do this week

Open a product you work on and list every animation you can find. For each one, write down three things: what it communicates, how long it lasts, and what happens with reduce motion turned on. Anything you can't justify in the first column is a candidate to remove. Anything over 400 ms is a candidate to shorten. And anything that still slides and zooms with reduce motion on is your first accessibility fix.