App motion & animation — why, when, and how much

Source: Material Design 3 motion (easing & duration tokens, spring schemes) + Material 1/2 standard curves, Apple HIG → Motion + WWDC23 "Animate with springs" (spring(duration:bounce:)), IBM Carbon (productive vs expressive) + Salesforce Lightning / Kinetics, Disney's 12 principles as applied to UI (Val Head, Designing Interface Animation), and WCAG 2.3.3 + prefers-reduced-motion. Cross-checked across these systems (June 2026). The through-line every system agrees on: motion is functional first — it explains a change; it is not decoration.

1. Why motion exists (the six jobs) — and when NOT to animate

Animate only when it does one of these jobs. If none apply, cut it.

• Orient — show where a thing came from / went to (a sheet rises from the button that summoned it).
• Feedback — confirm an input registered (tap → press-down, toggle → slide). The most valuable 100ms in the app.
• Continuity / spatial relationship — preserve object identity across a change so the user doesn't re-parse the screen (list row morphs into detail).
• Status — communicate ongoing/indeterminate work (progress, loading, sync).
• Focus / direction of attention — pull the eye to the one thing that changed (a new badge, an error).
• Delight — personality at a milestone, never on a routine action. Rare by definition.

Do NOT animate: high-frequency repeated actions (typing, scrolling content, list reordering the user drives), anything on the critical path to a result the user is waiting for (don't gate data behind a 400ms flourish), destructive-action confirmations (be instant and clear), or motion that fires on every keystroke/poll. If it plays more than a few times per session and isn't feedback, it will annoy. When unsure: ship it static, add motion only where the static version feels confusing or abrupt.