You don't need animations

Every animation needs a job#

The first filter is whether the animation has a job: “Before you start animating, ask yourself: what’s the purpose of this animation?” A purposeful animation can answer that in one sentence.

His four examples cover different jobs. A marketing animation for Linear’s Product Intelligence explains the feature inside the first viewport. A subtle scale-down on button press gives feedback and “helps the interface feel more alive and responsive.” Sonner’s toast enters from the direction it later leaves, and that spatial consistency makes swipe-to-dismiss intuitive. The fourth is the honest one: a morphing feedback component exists to delight, which is fine “as long as the user will rarely interact with it.”

Frequency decides#

That last example becomes the organising rule: “How often users will see an animation is a key factor in deciding whether to animate or not.” Emil uses Raycast hundreds of times a day; it has no launch animation, and he calls that optimal, because he opens it with a goal and does not need to be delighted. Keyboard-initiated actions, repeated hundreds of times a day, feel “slow, delayed, and disconnected” when animated, so “You should never animate them.” His skill file turns this into frequency tiers.

100+ times/day (keyboard shortcuts, command palette toggle)  No animation. Ever.Tens of times/day (hover effects, list navigation)  Remove or drastically reduceOccasional (modals, drawers, toasts)  Standard animationRare/first-time (onboarding, feedback forms, celebrations)  Can add delight

Rauno Freiberg arrived at the same place. In Invisible Details of Interaction Design he admits he loves to animate everything, then notes that a command menu fade at hundreds of uses a day “does start to feel more like cognitive burden.” On bmrks.com he animated the active indicator and list items, found them sluggish after a couple of days even after making them snappier, and once removed “suddenly felt like I was moving much faster.” macOS context menus and the App Switcher never animate either; a keypress feels mechanical, so leaving motion out is not jarring. See Frequency and novelty.

Fast, and under 300ms#

The other half of the essay is speed. Outside marketing sites, animations have to be fast: they improve perceived performance and keep the interface connected to what the user just did. A faster-spinning spinner makes an app seem to load faster though load time is unchanged, and a 180ms dropdown feels more responsive than a 400ms one. His duration rule of thumb is under 300ms.

.dropdown-fast { transition-duration: 180ms; }.dropdown-slow { transition-duration: 400ms; }

Tooltips get a note: delay the first to prevent accidental activation, but once one is open the next should appear with no delay and no animation, which “feels faster without defeating the purpose of the initial delay.” shadcn, quoted in Emil’s post about his course, put it in one line: design engineering “is mostly deciding what not to animate.”

The habit: before you add a transition, write down its purpose and estimate how many times a day the same person sees it. If the purpose is “it looks nice” and the count is high, delete it; the goal “is not to animate for animation’s sake, it’s to build great user interfaces.” The rest of this chapter is about the other case: real purpose, low count, made fast.