# You don't need animations · Motion Emil Kowalski opens [You Don’t Need Animations](https://emilkowal.ski/ui/you-dont-need-animations) by granting the case for motion before he takes most of it away. Done right, animations make an interface feel “predictable, faster, and more enjoyable to use.” Done wrong, they cost you the user’s trust. ### 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** (An animation that exists to do a specific job for the user, such as explaining, giving feedback, or keeping space consistent, rather than to decorate.) 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](https://github.com/emilkowalski/skill/blob/main/skills/emil-design-eng/SKILL.md) turns this into **frequency tiers** (Emil Kowalski's table that maps how often an interaction happens to how much animation it should get, from none at all to deliberate delight.). > Figure. SKILL.mdEmil Kowalski, emil-design-eng Rauno Freiberg arrived at the same place. In [Invisible Details of Interaction Design](https://rauno.me/craft/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](https://learn-ui.com/chapters/invisible-details/frequency-and-novelty). Source The four examples and the frequency argument are in the “Purposeful animations” and “Frequency of use” sections of You Don’t Need Animations. The tier table is from his public design engineering skill file. ### 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** (Emil Kowalski's guideline that UI animations should generally stay under 300ms, with marketing and explanatory animation as the exception.) is under 300ms. > Figure. CSSIllustration 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.