design-animation-system

Design Animation System

Build a coherent, reusable animation system that enforces brand personality, reduces cognitive load, and communicates state changes clearly across a product.

Why This Is Best Practice

Adopted by: Google Material Design, Apple Human Interface Guidelines, IBM Carbon Design System, Shopify Polaris Impact: Consistent motion reduces perceived task time by ~15% (Nielsen Norman Group); systematic animation tokens cut inconsistent implementation by 60% in multi-team projects Why best: Disney's 12 principles — squash-and-stretch, anticipation, follow-through, ease-in/ease-out — remain the canonical motion vocabulary. Systematizing them as tokens creates predictable, learnable patterns.

Sources: Thomas & Johnston (1981); Google Material Design motion spec; W3C CSS Animations Level 1

Steps

1. Audit current motion — catalog all existing animations in the product; identify inconsistencies, missing states, and conflicting durations.
2. Define motion values — establish a duration scale (e.g., 100ms micro, 200ms standard, 400ms complex, 600ms page) and map to interaction types.
3. Choose easing library — select 3–5 named curves (ease-in, ease-out, ease-in-out, spring, linear) aligned with Disney ease principles; document each use case.
4. Map motion to meaning — assign easing and duration to semantic intent: entrances use ease-out, exits use ease-in, emphasis uses spring or bounce.
5. Define 12-principle usage rules — specify which Disney principles apply to which component types (e.g., squash-and-stretch for feedback, anticipation for navigation).
6. Create animation tokens — export durations, curves, and delays as design tokens (CSS custom properties or JSON) consumed by code and design tools.
7. Build component-level motion specs — document per-component animation: trigger, property animated, duration, easing, delay, and stagger rules.
8. Establish accessibility rules — define reduced-motion fallbacks for every animated component using prefers-reduced-motion; no animation should be the only indicator of state.
9. Validate in code — implement tokens in the front-end; test in slow-motion (quarter speed) to catch overshoots and timing errors.
10. Document with live examples — publish animated examples in the design system storybook; include do/don't side-by-sides.

Rules

• Duration must scale with spatial distance: large elements moving far use longer durations than small elements moving short distances.
• Every animation must have a prefers-reduced-motion counterpart — either instant or cross-fade only.
• Never animate more than 3 properties simultaneously on a single element; isolate transform and opacity for GPU compositing.
• Easing curves must be purposeful — no linear easing for natural-feeling motion.
• Spring animations must be critically damped or underdamped by ≤10% to avoid infinite bounce.

Common Mistakes

• Using one duration for everything — flat timing destroys hierarchy; users cannot distinguish micro-feedback from major transitions.
• Skipping reduced-motion support — violates WCAG 2.1 Success Criterion 2.3.3; causes vestibular disorders in affected users.
• Animating layout properties (width/height/top/left) — triggers reflow; always prefer transform and opacity for performance.
• Designing animations only in static prototypes — 60fps feel cannot be judged in Figma; always validate in browser or native runtime.
• No stagger logic for lists — animating all list items simultaneously looks mechanical; stagger at 30–50ms per item.

When NOT to Use

• Single-page utilities with no state transitions (no motion needed)
• High-frequency data dashboards where animation distracts from data reading
• Contexts where battery or performance constraints dominate (e.g., embedded devices)