When to Animate

Before reaching for motion or writing a single transition, ask whether the interaction should animate at all. Most should not. The governing rule is the frequency-delight inverse: the more often a user performs an action, the less animation it deserves. Rare interactions earn personality. Frequent ones earn silence.

This isn't minimalism for its own sake. It's respect for the user's time. An animation that feels charming on first encounter feels slow by the tenth and infuriating by the hundredth. The difference between a polished interface and an annoying one is knowing where that threshold falls.

The frequency test

Every interaction fits somewhere on this spectrum:

| Frequency | Examples | Decision | |---|---|---| | 100+ times a day | Keyboard shortcuts, command palette, arrow-key nav, tab/focus | Never animate. | | Tens of times a day | Hover effects, list navigation, link rollovers | Remove or radically reduce | | Occasional | Modals, drawers, tooltips, toasts | Standard animation | | Rare or first-time | Onboarding, success states, milestones | Room for delight |

The critical row is the first one. Keyboard-initiated actions should never animate. Keyboards are the tool of power users who chose them because they're faster than the mouse. Adding a 200ms transition to a keyboard shortcut is punishing your most engaged users for being efficient.

This applies equally to focus rings, text selection, and command-palette toggles. These happen so fast that any transition reads as lag. The eye can't track sub-100ms motion on non-spatial changes—it just registers "this feels slow."

The four purposes of motion

Once you've confirmed the interaction is rare enough to animate, name its purpose. If you can't place the animation in one of these four categories, don't add it:

Feedback — confirms that an action was received. A button that scales slightly on press. A toggle that slides into its new state. The user needs to know the system heard them, and motion provides that confirmation faster than any text label.

Orientation — shows spatial relationships. A drawer slides from the edge it's anchored to. A popover scales from the trigger that opened it. The user needs to understand where things are in the interface, and directional motion builds that mental model. (This is why the "emerge from trigger" principle matters—an overlay that fades in from nowhere gives no spatial information.)

Continuity — preserves context across state changes. A tab indicator slides from one tab to the next. A shared element morphs between a list item and its detail view. The user needs to understand that they haven't left the current context—that this is a transition, not a navigation.

Delight — adds personality. A confetti burst on a completed milestone. A subtle spring overshoot on a notification badge. These are the animations people remember, and they only work because they're rare. If every interaction had personality, none of them would.

The test in practice

Consider a search input. The user types a query, results appear below. Should the results animate in?

Frequency: High—users may search dozens of times in a session.
Purpose: You could argue "orientation" (results emerge from the search field), but results appearing is expected behavior. The user typed; they know results will follow.
Decision: No animation. Or at most, a 100ms opacity fade—imperceptible enough to avoid feeling instant, fast enough to never feel slow.

Now consider a modal dialog triggered by clicking a "Delete account" button.

Frequency: Once, maybe ever.
Purpose: Orientation (the modal should emerge from the trigger button) and feedback (the system is responding to a significant action).
Decision: Animate the entrance. Use a 200–300ms ease-out transition with scale and opacity. This is the kind of rare, high-stakes interaction that earns motion.

Common mistakes

Animating everything because the design system has a transition token. Design tokens are tools, not requirements. A transition-duration: 200ms token in your system doesn't mean every component should use it—it means components that need animation have a consistent duration to reach for.

Animating page navigation with a 600ms transition. The user wanted to go somewhere. You're holding them hostage with a decorative cross-fade. Page transitions should be 200ms at most, and in most cases, an instant swap with a shared-element transition on the key content is better than animating the entire viewport.

Animating focus rings or text selection. These happen at the speed of keyboard input. Any transition duration reads as input delay. Set transition: none on focus-visible outlines.

The principle

Motion is communication, not decoration. Every animation should answer the question: what is this telling the user? If the answer is "nothing—it just looks nice," remove it. The absence of motion is itself a design decision, and it's the right one more often than most developers believe.