You don't need animations
Emil Kowalski opens You Don’t Need Animations by granting the case for motion before he takes most of it away. Done right, he writes, animations make an interface feel “predictable, faster, and more enjoyable to use.” Done wrong, they make it feel unpredictable, slow, and annoying, and they can cost you the user’s trust. The first filter, then, is not which easing or which library. It 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 question in one sentence. If it cannot, he would rather ship nothing.
His examples are worth holding onto because they cover different jobs. A marketing animation for Linear’s Product Intelligence explains what the feature does inside the first viewport, where a static asset would have explained less. A subtle scale-down when you press a button gives feedback and “helps the interface feel more alive and responsive.” Sonner’s toast enters with an animation for two reasons at once: a toast that simply appears would feel off, and because it arrives from the same direction it later leaves, it creates spatial consistency that makes the swipe-down-to-dismiss gesture feel intuitive. The fourth example is the honest one. A morphing feedback component exists to delight, and he says that is fine, but only “as long as the user will rarely interact with it.” Used several times a day, the same morph would become irritating, and the animation would start slowing people down.
That last example turns into the rule that organises the rest of his thinking: “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 the optimal experience, because when he opens it he has a goal in mind and does not need to be delighted. A hover effect used many times a day would, he thinks, benefit most from no animation at all. Keyboard-initiated actions are the extreme case: repeated hundreds of times a day, an animation makes them feel “slow, delayed, and disconnected,” and his instruction is blunt: “You should never animate them.” The skill file he later published turns this into frequency tiers. Something done 100 or more times a day, such as a keyboard shortcut or a command palette toggle: no animation, ever. Tens of times a day, such as hover effects and list navigation: remove or drastically reduce. Occasional, such as modals, drawers, and toasts: standard animation. Rare or first-time, such as onboarding and celebrations: this is where delight is allowed.
Rauno Freiberg arrived at the same place from his own work, and it is worth citing both because they agree for different reasons. In the Frequency and Novelty section of Invisible Details of Interaction Design, Rauno admits that as a designer he loves to animate everything, and then describes command menus: it is tempting to throw an opacity and scale fade on the overlay, but at hundreds of uses a day the same animation “does start to feel more like cognitive burden.” His evidence is personal. Working on the bookmarking tool bmrks.com, he animated the active indicator and list items and felt great about it; after a couple of days they felt sluggish, even after he made the motion snappier, and when he removed motion from the core interactions he “suddenly felt like I was moving much faster.” He also points at macOS, where context menus appear without motion and the App Switcher overlay never animates. Emil frames the same lesson as frequency; Rauno adds that a keypress feels mechanical rather than visceral, so leaving the motion out does not feel jarring. We covered Rauno’s side in Frequency and novelty.
The other half of the essay is about speed, and the numbers are specific. Unless you are working on a marketing site, 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 even though load time is unchanged. A 180ms dropdown feels more responsive than a 400ms one. His duration rule of thumb is that UI animations should generally stay under 300ms. Tooltips get their own note: the first one should be delayed to prevent accidental activation, but once one is open, hovering the next should open it with no delay and no animation, which “feels faster without defeating the purpose of the initial delay.”
What to take from this is a habit rather than a number. Before you reach for a transition, write down its purpose and estimate how many times a day the same person will see it. If the purpose is “it looks nice” and the count is high, delete it; Emil says the goal “is not to animate for animation’s sake, it’s to build great user interfaces,” and that sometimes the best animation is none. If the purpose is real and the count is low, keep it, and make it fast. Everything else in this chapter is about that second case.