Animation can transform an interface. It can also ruin one.
The difference comes down to intent. Every animation you add creates a tradeoff between expressiveness and efficiency. Get it right and your product feels polished, responsive, alive. Get it wrong and users feel like they're wading through molasses.
The goal isn't to animate everything. It's to know when motion serves the experience and when it gets in the way.
TL;DR
- Every animation needs a reason. If you can't articulate why something animates, remove it
- Frequency kills delight. What feels magical once becomes annoying after a hundred uses
- Speed creates perceived performance. Fast animations make your app feel responsive even when the underlying operation is slow
- The 300ms ceiling. Most UI animations should stay under this threshold
- Context shapes expectations. Product UI needs efficiency, marketing pages can be expressive
- When unsure, skip the animation. No animation beats bad animation
The Purpose Test
Before adding any animation, ask one question: what does this accomplish?
Animation serves four purposes in interfaces:
- Feedback confirms user actions. A button that slightly compresses on press tells users their input registered before any server response arrives.
- Orientation shows spatial relationships. When a panel slides in from the right, users understand it came from somewhere and can return there.
- Continuity maintains context during transitions. A list item expanding into a detail view shows these are the same entity, not two disconnected screens.
- Delight creates memorable moments. A celebration animation after completing an onboarding flow leaves a positive impression.
Click the heart
Feedback: The button compresses on press
Delight: The heart bounces and fills with color
A simple like button can demonstrate two purposes at once. The scale down on press provides feedback. The bounce and color fill create delight. Neither animation is strictly necessary, but together they make the interaction feel satisfying.
But delight has a shelf life. That bouncy heart feels great the first few times. On a social feed where you might like dozens of posts, the same animation would become exhausting.
Frequency Changes Everything
How often users encounter an animation determines whether it helps or hurts.
Open Spotlight on your Mac. Notice there's no entrance animation. It just appears. Apple made this choice deliberately. Power users invoke Spotlight hundreds of times daily. Any animation, even a fast one, would accumulate into noticeable friction.
Toggle the menu above using J (animated) and K (instant). After a few toggles, the difference becomes clear. The animated version feels fluid in isolation. But imagine using it every minute of your workday. Suddenly instant feels better.
This principle applies across your interface:
| Frequency | Animation Approach |
|---|---|
| Once per session | Elaborate, expressive |
| A few times per session | Subtle, purposeful |
| Many times per hour | Minimal or none |
| Continuous/repeated | None |
The mistake I see most often: treating every interaction as if users will only see it once. Your welcome modal can be expressive. Your navigation can't.
Keyboard Users Are Different
When someone reaches for their keyboard instead of their mouse, they're signaling intent. They want speed. They've committed the shortcut to muscle memory and expect the interface to keep up.
Focus the list above and navigate with arrow keys. Toggle animation with Shift. Feel how the animated highlight creates a disconnect between your keystrokes and the visual response?
Keyboard-initiated actions should generally skip animation entirely. The user's mental model is "I pressed down, I'm now on the next item." Any delay between input and outcome creates cognitive dissonance.
This extends beyond list navigation. Command palettes, tab switching, menu traversal. Anywhere users can operate through keyboard shortcuts, animation becomes a liability.
The 300ms Ceiling
Most UI animations should complete in 300 milliseconds or less. This isn't arbitrary. It's based on human perception thresholds.
- Under 100ms feels instantaneous. Good for micro-interactions like button presses.
- 100ms to 300ms feels responsive. The sweet spot for most transitions.
- 300ms to 500ms is noticeable but acceptable. Use sparingly for larger movements.
- Over 500ms feels slow. Reserve for intentional dramatic moments.
Click both dropdowns. The 180ms version feels snappy. The 400ms version feels sluggish. Same easing, same elements, but the duration changes the entire character of the interaction.
When you find yourself thinking "this animation needs to be longer," question that instinct. Usually the solution is to adjust the easing curve, not extend the duration.
Perceived Speed
Animation doesn't just affect feel. It affects how fast your application seems to perform.
Same wait time, different perceived speed
A faster spinner creates the illusion that your app is working harder, even though the actual load time is identical.
Both spinners represent the same wait time. But the faster rotation creates an illusion of activity. Users perceive the application as working harder, even though nothing changed about the actual load time.
This works in the other direction too. A slow, laggy animation makes users feel like your entire application is slow, even when the underlying performance is fine.
Three ways animation affects perceived performance:
- Skeleton screens that pulse suggest content is arriving, making waits feel shorter than blank loading states.
- Optimistic updates that animate immediately suggest instant responsiveness, even when the server hasn't confirmed the action.
- Progressive reveals that show content as it loads feel faster than waiting for everything before showing anything.
Tooltips and the Delay Pattern
Tooltips need special handling. They require a delay before appearing to prevent accidental triggers, but once one tooltip is open, switching between tooltips should be instant.
Hover over each icon
First tooltip waits 400ms. After that, moving between icons shows tooltips instantly.
Hover over the icons. The first tooltip waits 400ms. After that, moving between icons shows tooltips immediately with no animation.
This pattern exists because the contexts are different. Initial trigger: user might be just passing through, so wait. Subsequent triggers: user is actively exploring, so respond instantly.
The same logic applies to nested menus, tab groups, and any interface where users scan across multiple elements.
Element Size Affects Duration
Bigger elements need longer animations. This feels counterintuitive until you think about physics.
Bigger elements carry more visual weight. They feel more natural with longer durations, like heavier objects in the physical world.
A small indicator moving quickly feels natural. A large modal moving at the same speed feels weightless and artificial. Visual weight creates expectations of physical weight.
General guidelines:
| Element Size | Duration Range |
|---|---|
| Small (icons, badges) | 100ms to 200ms |
| Medium (buttons, cards) | 150ms to 300ms |
| Large (modals, panels) | 200ms to 400ms |
| Full screen | 300ms to 500ms |
These aren't rules, they're starting points. The specific duration depends on the easing curve, the distance traveled, and the overall tone of your interface.
Product vs Marketing
Your marketing site and your product serve different purposes. Animation should reflect this.
Product UI optimizes for repeated use. Users have tasks to complete. They've already bought into your product. Animation should enhance efficiency, not demonstrate creativity.
Marketing pages optimize for first impressions. Users are evaluating whether to engage. Animation can create wow moments that make your product memorable.
The same component might animate differently in these contexts. A card expanding could have a subtle 200ms transition in your dashboard and a dramatic 500ms spring-based animation on your landing page.
This extends to specific sections too. Your pricing page is marketing. Your checkout flow is product. Even on a marketing site, once users enter a functional flow, dial back the expression.
When Animation Hurts
Some situations call for removing animation entirely:
- Error states. When something goes wrong, users want information, not flourish. A shake animation on failed login is fine. Elaborate transitions while displaying error details slow users down.
- Accessibility contexts. Users who enable reduced motion preferences have reasons. Vestibular disorders, motion sensitivity, or simply preference. Respect the
prefers-reduced-motionmedia query. - Data-heavy interfaces. Dashboards, analytics tools, spreadsheets. Users are processing information. Animation competes for the same cognitive resources they need for understanding the data.
- Low-powered devices. Animation that feels smooth on your development machine might stutter on older phones. Test on real devices, especially if your audience includes budget hardware.
CSS
@media (prefers-reduced-motion: reduce) {
* {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}Building Intuition
Reading about animation timing only gets you so far. You develop judgment through practice.
- Slow things down. Screen record your animations and play back at 0.25x speed. Details invisible at normal speed become obvious.
- Test in context. An animation that feels perfect in isolation might feel wrong within your actual interface. Always test where the animation will live.
- Watch others. Study products known for polish. Linear, Stripe, Vercel, Raycast. Don't copy their animations, but notice their patterns. When do they animate? When don't they?
- Err toward removing. When unsure whether to animate, don't. You can always add motion later. Removing animation that users have grown accustomed to is harder.
The Restraint Principle
The best animated interfaces don't feel animated. They feel natural.
Animation should be invisible in the sense that users don't notice it. They notice when it's missing (something feels off) or when it's excessive (something feels slow). But well-executed animation simply makes the interface feel right without calling attention to itself.
This requires restraint. The temptation is to animate because you can. The skill is knowing when animation serves the user and when it serves your desire to show off.
Build interfaces that users want to use every day. Sometimes that means elaborate motion. More often, it means getting out of the way and letting people accomplish their goals without friction.
Conclusion
Animation is a tool, not a goal. It should make interfaces more understandable, more responsive, and more pleasant. When it does the opposite, it doesn't belong.
Remember the core questions: What purpose does this serve? How often will users see it? Does the duration feel right for the context?
Start with no animation. Add it only when you can articulate why. And when you do add it, keep it fast, keep it subtle, and keep it purposeful. That's how animation becomes invisible infrastructure rather than visible decoration.