Interface animation: when it helps and how to reduce motion

Animate an element when the motion explains something: that an action was received, that the screen changed state, or where the person just went. Most transitions fit between 100 and 400 milliseconds (NN/g, Executing UX Animations). People who turned on the reduce motion setting on their device should get the page without slides, and CSS picks up that request through prefers-reduced-motion.

What animation is for

The human eye is very sensitive to motion, especially at the edge of vision. That’s both the strength and the risk of animation. A 2020 NN/g article sorts out the uses where this stolen attention pays off (NN/g, The Role of Animation and Motion in UX):

Feedback. A menu that slides in after a tap confirms the tap worked.
State change. A pencil that morphs into a floppy disk shows the switch from editing to saving.
Sense of place. Zooming in and out helps you tell whether you went down or up a level of content.
Usage hint. A panel that rises from the bottom suggests you can close it by pulling it down.

The same article shows a store where animation was missing. The cart count changes on its own, small and far from the buy button. People don’t notice the change and may end up adding the same product twice.

Feedback has to arrive fast to feel like a result of the click. A 2014 NN/g piece puts that limit at 0.1 seconds between the action and the start of the effect (NN/g, Animation for Attention and Comprehension).

When it gets in the way

Motion without a job turns into distraction. The 2020 article points to a squiggle that wiggles next to the text and adds nothing, and to a flashing clock announcing the end of a fake sale. The second one is manipulation, since it uses fear of missing out to push the purchase (NN/g).

Repetition has a cost too. In NN/g’s tests, a common complaint is that an animation was nice the first time and annoying from the second time on (NN/g). The article’s example is a hidden menu that only shows up at the end of a long sequence, replayed on every use, with no way to skip it.

The kind of motion changes how much attention it grabs. An element that slides in pulls the eye faster than one that simply fades in without changing position (NN/g). For something people need to notice right away, the slide works. For a supporting feature, the soft fade is less intrusive.

How long it should last

NN/g’s article on execution gives the reference ranges (NN/g, Executing UX Animations):

About 100 ms for simple feedback, like checking a box or flipping a toggle.
200 to 300 ms for a big change on screen, like a dialog sliding in.
400 ms is already slow, fine only for long movements on large screens.
From 500 ms on, the animation starts to feel like waiting.

Two rules round out the list in the same piece. Exiting can be a bit faster than entering, and the more often an animation shows up, the shorter it should be. The most common curve starts fast and slows down at the end, called ease-out, because the eye can predict where the element will stop.

Drag and drop uses the same idea, with a short animation that shows where the item will land, as I cover in the post on drag and drop.

Who asks for less motion

For some people, motion on screen isn’t a matter of taste. People with vestibular disorders, tied to balance and the inner ear, can get dizziness, nausea and migraines. Sometimes they even need bed rest to recover (W3C, Understanding 2.3.3). Parallax effects, where the background moves at a different speed from the foreground, are among the triggers listed.

Operating systems have a setting for this, found in the accessibility settings on iPhone, Android, Windows and macOS. The browser passes that choice on to the site through the prefers-reduced-motion media query, which has worked in all major browsers since January 2020 (MDN, prefers-reduced-motion).

The reduce value says the person wants less motion, ideally with nothing that isn’t necessary (web.dev, prefers-reduced-motion). The guide points out two things people often miss:

JavaScript animation has to listen for the change. CSS reacts on its own when someone flips the setting, but a script has to check again or listen for the change event.
Animated images count too. With <picture> and the media attribute, the browser shows the still version to people who asked for less motion.

The W3C accessibility guidelines cover this in success criterion 2.3.3, at level AAA, the strictest one. Motion animation triggered by interaction must be possible to turn off, unless it’s essential (W3C, WCAG 2.2). Motion that starts on its own and lasts more than five seconds falls under a different criterion, 2.2.2, which I explained in the post on carousels in ecommerce.

What the browser animates easily

Not every property costs the same to animate. The web.dev guide asks you to keep animation on transform and opacity whenever you can (web.dev, high-performance CSS animations). Moving things with top and left, or changing width and height, forces the browser to recalculate layout and repaint the page on every frame.

The same guide treats will-change as a last resort. It forces the element onto its own layer, which can cause other problems, so it should only come in when real jank shows up.

How I built it on kahue.net

On the site’s pages, blocks below the fold come in with a 14 pixel slide and a fade, over 420 ms. The curve is the kind that slows down at the end, and only transform and opacity change. The top of the page stays still on purpose. It’s the first thing people see, and animating what was already on screen would only delay reading.

When several items come in together, each one starts 70 ms after the previous one, but the delay stops at the third. After that, waiting adds nothing for someone who’s already decided to read.

The animation is a layer on top, not a requirement. Without JavaScript, no motion rule applies, and the content shows up complete and in place. Anyone who skips blocks with an anchor link or the End key won’t hit empty space either, because every block left behind gets revealed.

The reduced motion request is handled in CSS, not in the script, so it works even if the script fails. With it on, blocks show up already in place, smooth scrolling turns into a direct jump and no transition runs. In the screen gallery on the case pages, switching images slides over 180 ms, and the code checks the preference on every switch. If someone turns the setting on with the gallery open, the next image already appears without sliding.

Where the sources disagree

The first point is duration for motion the person didn’t trigger. NN/g’s 2020 piece treats 400 ms as very slow (NN/g). The 2014 one accepts slower transitions with little movement when the animation comes from scrolling or loading (NN/g). The 420 ms on kahue.net go past the 2020 ceiling and fit the 2014 rule.

The second is what to do with the reduced motion request. NN/g’s 2020 article talks about removing animations (NN/g). The W3C definition, though, doesn’t count changes in color or opacity as motion animation (W3C, motion animation definition). MDN talks about removing, reducing or replacing motion (MDN). By the W3C yardstick, a fade without a slide would still be allowed.

kahue.net went with the stricter side. The global rule turns off every transition, color ones included, which goes beyond what the criterion asks for.

The common mistake: hiding content until the animation runs

Plenty of sites start with blocks invisible in CSS and trust a script to show them at the right moment. If the script is late, fails or gets blocked, the text never appears. The animation, which should be decoration, ends up deciding whether people get to read at all.

The fix is to flip the order. The page loads complete, and the hidden state only kicks in after the script confirms it’s running. People who asked for less motion, people browsing without scripts and search crawlers all get the same content.