Open any small, classic online store — some regional hardware shop — click the "add to cart" button on a product, and watch the counter in the corner blink "+1." Chances are, you didn't actually see the animation itself — only the final number. And that's not a vision problem, it's basic physiology — while your gaze was flying across the screen, your brain simply switched the picture off.
During a saccade (a fast eye jump), vision shuts off for roughly 150 milliseconds: the brain doesn't really need a blurred frame, so it cuts it out and papers over the gap with the final image. A 100 ms counter animation, triggered at the moment of the click, plays out entirely inside that blind window — your gaze lands on an already-finished result and sees a static number. The time and resources spent on the animation are wasted.
The VR industry has already monetized this property — there are patents for turning off rendering during saccades, since there's no point computing frames the brain will ignore anyway. Web design, for the most part, keeps producing animation that will go unnoticed by users.
From this it follows that animation duration makes more sense to calculate from the gaze first, not from the event itself:
- What happens under the cursor — where the person is already looking — can be very fast.
- What happens on the other side of the screen should either last longer (to survive the gaze's flight time), or start with a tiny delay, or simply not rely on motion at all.
From 100 to 400 ms: how much time a person actually needs
The bounds within which this conversation about timing even makes sense have been known for a long time and haven't shifted since — the biology of perception, unfortunately, hasn't changed in the last hundred years.
Jakob Nielsen boiled it down to three numbers back in 1993, building on research from the sixties:
- up to 0.1 second — a response feels like the user's own action;
- up to 1 second — the train of thought doesn't break;
- 10 seconds — the point at which attention runs out.
Physiology itself prevents going any lower: according to the classic Model Human Processor (Card, Moran, and Newell), perceiving a visual event takes a person roughly 200–250 ms, so a transition noticeably shorter than that range reads not as motion but as a switch.
And economics prevents going much slower: in 1982, Walter Doherty of IBM showed that cutting system response time from two seconds to 400 ms boosted operator productivity far more than the time saved would suggest. The reason is that a pause longer than half a second is enough to erase the plan for the next step from someone's head — the person has to remember what they were even trying to do.
The Nielsen Norman Group arrives at the same range from the practical side: the working range for animation is 100–400 ms, where 400 is already quite slow and reserved only for large movements, and half a second is unjustifiably long. You could say the entire discipline of timing is about tuning dozens of scenarios that all happen within a third of a second.
Why ease-in has no place in interfaces
Two transitions of 300 ms each can feel completely different — that's determined by the easing curve. Emil Kowalski, who built the animations for Linear and Vercel, demonstrates this with two identical dropdowns: one opens with ease-out (sharp start, gentle deceleration), the other with ease-in (slow ramp-up). The duration is identical, but the second one consistently feels slower.
The reason lies in where the motion lands in the first frames:
- ease-out delivers most of the movement immediately — the visual confirmation arrives exactly when the gaze is waiting for it, and the deceleration at the end no longer reads as waiting;
- ease-in does the opposite — it stretches out the pause exactly where a person is waiting for a reaction.
Kowalski puts it simply: ease-in has no place in interfaces, ease-out works for any response, and ease-in-out is reserved for elements that move across the screen without appearing or disappearing.
The same asymmetry governs appearing and disappearing: NN/g notes that an incoming element needs a bit more time than an outgoing one — a modal opens in 300 ms and closes in 200–250. The incoming element needs to be noticed and taken in; the outgoing one doesn't — it no longer serves any purpose.
Intentional binding: why a click gets forgiven for lag, and hover doesn't
In 2002, Patrick Haggard and colleagues described an effect that dozens of labs have since replicated: the interval between an intentional action and its consequence feels subjectively compressed. Press a key, hear a sound — the gap feels shorter than it actually was. This effect was named intentional binding.
It breaks down immediately, though, if the action wasn't deliberate but passive: if the action was involuntary, or someone else triggered it, the brain doesn't smooth anything over. The brain compresses the pause only when the action was your own — that, essentially, is how the sense of "I did that" is born.
In practice, this directly sets the timing rules:
- A click is a deliberate action, so the brain compresses the subjective wait on its own: a small response delay is partly absorbed by the psyche's own machinery (though the base tactile response still has to fit within Nielsen's 100 ms to preserve a sense of tangibility).
- Cursor hover doesn't count as an action in this sense — it's closer to just looking, and it doesn't get that same credit.
For the most part, designers found this distinction long before any theory existed: GitLab, for instance, animates hover in 200 ms, and compresses it to 100 ms in dense lists — where the cursor flies past dozens of rows, even a straight 200 ms starts to feel slow.
The 300 ms delay as a filter against false hovers
Hover also doesn't always need a response at all. The classic problem with hover menus is that they spam dropdowns at every random mouse twitch. The Baymard Institute, which has spent years testing e-commerce navigation, fixes this with a 300–500 ms delay before opening — and notes that 60% of major sites don't do this.
This doesn't get in the way of a deliberate click, but it does prevent false openings triggered by accidental mouse movement. Tooltips have followed this rule for decades — Windows' default tooltip delay is 500 ms.
The same logic applies in reverse for closing: a menu shouldn't snap shut the instant the cursor accidentally slips off the edge on its way to a submenu — a closing delay is just as necessary.
Peripheral vision: why background animation is distracting
Motion at the periphery seizes attention involuntarily. In Remington, Johnson, and Yantis's 1992 experiments, sudden stimuli pulled test subjects' gaze even when they knew exactly that they shouldn't look there and were actively trying not to. Peripheral vision is wired to react to motion faster than conscious awareness — any flicker in the corner of the screen instantly hijacks focus.
On screen, this reflex only gets in the way: any endless loop at the periphery will keep pulling a person away from their task.
For part of the audience, this isn't just a matter of basic discomfort: roughly 35% of people over forty have experienced some form of vestibular dysfunction, and large-scale motion on screen can trigger dizziness for them. That's why the prefers-reduced-motion media query isn't even up for debate — it's a couple of lines of CSS that belong in every project.
Summary values for a design system
Animation timing depends on three parameters:
- where the user's focus currently is — this determines how much of the animation will actually reach the viewer (100 ms is enough under the cursor, while an animation that starts during a saccade is wasted from the first frame);
- whether there's intent behind the interaction — a click earns a pause thanks to the brain's own time compression; hover has no such credit, and needs either an instant, delay-free reaction or a filtering pause;
- the context the element lives in — this sets the upper bound: in a work interface, animation serves the task and should stay within 100–300 ms, while on a landing page a person usually isn't in a hurry and can tolerate roughly twice that.
The ranges below are a starting reference point, still worth tuning on the actual mockup to match the feel and needs of a specific interface (even a 50 ms difference is noticeably perceptible):
| Pattern | Timing | Curve | Examples |
|---|---|---|---|
| Hover | 100–200 ms | ease-out | Button highlight, link underline, shadow on a product card |
| Press (active) | up to 100 ms | ease-out | intentional binding does the work. Button press-down, checkbox state change, tab switch |
| Exiting a state | 25–50 ms shorter than entering | ease-out | A button should fade out a bit faster than it faded in |
| Hover dropdowns and tooltips | opening delay 300–500 ms, animation itself 150–250 ms | ease-out, closing delay required | Catalog menu, icon tooltip, video timeline preview |
| Modals and panels | in 200–300 ms, out 150–250 ms | ease-out | Order confirmation window, side cart, filter drawer |
| Result far from the cursor | +50–100 ms added to duration or start | ease-out | "Saved" notification in a corner, notification badge |
| Large transitions | 200–250 ms (desktop), 300–400 ms (mobile) | ease-out / ease-in-out | Screen change, card expanding to full page, step transition in a form |
| Landing page scroll animations | 400–600 ms | depends on the scenario | Benefits block sliding in on scroll, stat counters ticking up to their value |
| Frequently repeated elements | twice as fast, or no animation at all | — | Admin table rows, sidebar items, task list items |
In practice, all of this often boils down to a simple pair of values: 180/90 ms. 180 ms for hover gives a noticeable but non-distracting transition, and 90 ms for press fits within the threshold of an instant physical response.
In a system like this, timing stops being a matter of taste and starts following the main rule of good design: confirm the user's action without demanding extra attention for itself.
Be the first to comment