When to reach for animation and when to leave it alone

Animation earns its place in an interface exactly once: when it helps the user understand what happened or what's about to happen.

That bar rules out a lot of animation that gets shipped.

A button that bounces on hover doesn't help you understand anything. A card with a perspective transform on hover doesn't help you understand anything. A loading skeleton that pulses in a wave pattern tells you something is loading, but a simpler shimmer accomplishes the same thing. Animation that's there for "delight" or "polish" without a specific job is usually just distraction.

What earns its place

When an element changes state and the change would otherwise be abrupt or confusing, animation communicates what happened. A menu item getting a checkmark is fine without animation. An entire list reordering because you checked that item benefits from the items moving into their new positions rather than jumping there. The user needs to track what moved.

When UI elements have a spatial model (a panel that slides in from the right, a modal that expands from a trigger) animation reinforces that model. The element appears where it came from. It returns when dismissed. The user maintains a mental model of where things are.

Loading states, progress, and async operations are the clearest case. Animation signals that something is happening and prevents the uncertainty that produces repeated clicks. This is functional, not decorative.

The fidelity trap

High-quality animation in a design file looks better than simple animation in a design file. This makes it easy to justify adding more.

In use, the math is different. Animation that runs on every interaction accumulates. A 300ms spring on every button hover is pleasant for the first few. By the twentieth button hover in a session, it's in the way. Duration and complexity that work beautifully in a prototype often read as sluggish in production when you're actually trying to get something done.

Prototype animation at the pace of real use. Run the flow through as fast as you actually work, not at the speed of a design presentation. That's when you find out whether the motion is helping or getting in the way.

Reduced motion

Every positional animation needs a reduced motion fallback. Not everyone who turns this on has a vestibular disorder. Many just prefer less visual noise. The fallback isn't a stripped-down experience; it's a different one that accomplishes the same goal.

Opacity transitions usually survive reduced motion. Position changes don't. A modal that fades in instead of sliding is a reasonable fallback. A modal that still slides because someone forgot the media query is not.

The most reliable approach: build reduced motion handling into every animation pattern from the start. Treating it as an afterthought produces the same result as not treating it at all. Except you have to find it in a future audit.