How long an animation should take

The question everybody guesses at

“How long should this animation be?” gets answered by feel, and feel drifts. The person who has watched their own transition four hundred times finds it too slow at 250ms and cuts it to 120ms, at which point it is a flicker for everybody who has never seen it before.

There are defensible numbers. They come from two facts: the eye needs a minimum exposure to register that something moved, and attention has a budget.

Working durations

These ranges match what the large design systems publish, and more importantly they match what survives testing.

• 70 to 120ms: a small element changing in place. A checkbox filling, a button’s background shifting on press, an icon swapping. Below about 60ms the change is perceived as instantaneous rather than as a movement, which is often exactly what you want for a press state.
• 150 to 250ms: a small element entering or leaving. A tooltip, a dropdown, a toast.
• 250 to 350ms: a panel, sheet, or dialogue crossing a meaningful part of the screen.
• 350 to 500ms: a full-screen transition, a page change, something covering most of the viewport.
• Above 500ms: reserve for something the user is watching deliberately: an onboarding illustration, a data visualisation building, a celebration. Not for anything that sits between a person and their task.

Two adjustments that matter more than the base number:

Exits are faster than entrances. Roughly 70 to 80 per cent of the entry duration. An arriving element is new information and the eye needs time to find it. A leaving element is already understood; lingering just makes the interface feel sticky.

Distance scales the duration, but not linearly. Doubling the travel distance does not mean doubling the time: that produces a crawl on large screens. Material Design’s published approach is a distance-based curve where duration grows roughly with the square root of distance; in practice, scaling time by about 1.4× for each doubling of distance keeps perceived speed constant. A 200px move at 250ms and a 800px move at 500ms feel like the same speed even though the second one is four times the distance at half the speed-per-pixel.

Why the same number feels wrong on different screens

A 300ms sheet transition tested on a 6-inch phone can feel sluggish on a 27-inch monitor and frantic on a television across a room. The reason is angular, not physical: what your eye tracks is degrees of visual field per second, and the same pixel distance subtends a very different angle at arm’s length than at three metres.

This is why published duration guidance almost always names a device class. Material’s numbers are phone numbers. Apple’s are tuned per platform, and tvOS motion is noticeably slower and larger than iOS motion for exactly this reason. Take any table of durations as calibrated for the screen it was measured on, then re-test.

Perceived duration is not measured duration

Two animations of identical length can feel different lengths.

• An animation with a long slow tail (a curve that spends its last third creeping the final few pixels) reads as longer than its clock time, because the end is the part you wait for. This is the single most common cause of “it feels slow” on a transition that measures 250ms.
• An animation that starts immediately reads as shorter, because the response latency is what people actually judge. A 300ms transition that begins on the same frame as the tap feels faster than a 200ms one that begins 100ms later.
• An animation you have seen before feels longer. Repeat exposure is why the durations you love on day one feel slow on day thirty, and why you should not trust your own judgement on something you have built.

The practical consequence: cut the tail before you cut the duration. Changing the curve so the last 10 per cent of the distance happens in the last 15 per cent of the time rather than the last 40 per cent will fix most “too slow” complaints without touching the number.

How to set your own numbers

1. Pick three durations, not twenty. Something like 150, 250 and 400ms covers nearly everything.
2. Write them down as named values, not as literals scattered through the code.
3. Test each on the slowest device you support, over a throttled connection, with someone who has not seen the product.
4. Record the result at 60fps and count frames. A 250ms transition is 15 frames at 60fps; if you count 28, something in your stack is adding time you did not budget for.

The free path

• ffmpeg will pull a screen recording apart into numbered frames so you can count: ffmpeg -i capture.mp4 -vf fps=60 frame_%04d.png. Counting frames is the only way to know the real duration rather than the intended one.
• Chrome DevTools and Firefox Profiler both show animation timing directly, free.
• OBS Studio records the screen at a known frame rate on Linux, Windows and macOS, free, and is the standard tool for this.

The limitation

None of these numbers are laws. They are a starting point calibrated on handheld screens for people with typical vision and typical reaction times, and they say nothing about a user with a motor impairment who needs more time to track a moving target, or about a power user who runs the same flow two hundred times a day and wants everything instant. A configurable speed multiplier serves both better than a perfect single value, and almost nobody ships one.