UI animation duration: timing by distance and purpose
The right UI animation duration depends on two things: how far something moves and why it's moving. Feedback on a press or hover should be close to instant, around 100ms to 200ms. Small movements and toggles sit around 200ms to 300ms. Large panels and page-level entrances can take longer, but rarely more than about half a second for anything the visitor is waiting on.
Why duration matters more than it seems
Research on response times, popularised in usability writing by Jakob Nielsen, describes rough thresholds: around a tenth of a second feels instantaneous, around one second keeps a person's train of thought, and much beyond that they start to lose focus. Interface animation lives mostly inside the first threshold. A hover that takes 400ms isn't slow in absolute terms, but it feels sluggish because the visitor expected the response to be immediate.
Duration also changes how a brand feels. Quick, crisp motion reads as efficient and technical; slightly longer, softer motion reads as calm or luxurious. Both work. What doesn't work is a mix, where one menu snaps and another drifts.
A duration scale by purpose
| Purpose | Typical duration | Examples |
|---|---|---|
| Instant feedback | About 100ms to 150ms | Hover colour, button press, focus ring, checkbox tick |
| Small state change | About 150ms to 250ms | Toggle switch, accordion icon, tab underline |
| Medium movement | About 250ms to 350ms | Dropdown menu, tooltip, small panel opening |
| Large movement | About 300ms to 500ms | Side sheet, modal, full-width panel |
| Decorative entrance | About 500ms to 1s | Hero headline rising in on load, a photo settling |
These ranges overlap on purpose: they're a starting point to tune by eye, not a standard. Material Design and other design systems publish similar scales, built as named tokens such as short, medium and long, so a team uses a handful of durations rather than inventing a new one for each component.
Rules of thumb
- Scale with distance. An element moving 20px shouldn't take as long as one crossing the screen. Bigger travel, a bit more time.
- Scale with size. Small elements move quicker; large panels need a little longer to avoid looking like a jump.
- Exits are faster than entrances. When something leaves, the visitor has already moved on. Roughly two-thirds of the entrance time is a common choice.
- Don't make people wait to act. If the visitor can't click until an animation ends, it's too long. Let input interrupt motion.
- Repeated actions get shorter. Something the visitor does fifty times a session, like opening a menu, should be faster than something they see once.
- Pair duration with the curve. A strong ease-out makes 200ms feel quicker than a linear 150ms, because most of the change happens at once.
Writing it in CSS
Store durations as custom properties, such as --dur-fast: 150ms and --dur-slow: 400ms, and reference them in every transition and animation. One change then retunes the whole site. Transition only the properties that change, such as transition: background-color var(--dur-fast) var(--ease), rather than transition: all, which animates things you didn't intend and can cost performance. Prefer animating transform and opacity, which browsers can usually run without recalculating layout.
Accessibility
Long or large animations can be uncomfortable for people with vestibular disorders. Honour prefers-reduced-motion: reduce by removing movement and keeping instant state changes. WCAG 2.2's success criterion 2.3.3, at level AAA, asks that motion triggered by interaction can be disabled unless it's essential, and 2.2.2 at level A covers automatically moving content that lasts more than five seconds. Prefers-reduced-motion shows how to implement the setting.
Durations in Anticode
Anticode's design engine defines two durations shared by all seven design systems: 150ms for interface feedback such as hover colours, link states and booking slots, and 700ms for the hero's entrance on load. They're paired with custom curves instead of the default ease: a strong ease-out for feedback and a longer, gliding ease-out for entrances. Brutalist's buttons use a slightly quicker 120ms press. Scroll-driven reveals follow scroll position rather than a duration, and under reduced motion all transitions and animations are switched off.
The Critic flags the default ease timing curve on every build, which is usually a sign that nobody chose the timing at all.
Questions people ask
How long should a hover transition be?
About 100ms to 150ms. Longer than that and the hover feels like it lags behind the pointer.
Why do my animations feel slow?
Usually the duration is long for the distance, the curve is linear or a gentle ease, or the visitor has to wait for the animation before they can act.
Should exit animations be faster than entrances?
Generally yes. Something leaving the screen can go quicker, since the visitor's attention has already moved on.