apply-easing-and-timing

name	apply-easing-and-timing
description	Use when choosing easing curves and durations for specific UI animations, transitions, or motion design decisions
source	Thomas & Johnston "The Illusion of Life: Disney Animation" (1981); Material Design motion spec (Google 2014); Lasseter "Principles of Traditional Animation Applied to 3D Computer Animation" SIGGRAPH (1987)
tags	["motion","easing","timing","animation","ux"]
verified	true

Apply Easing and Timing

Select the correct easing curve and duration for any animation so that motion feels natural, purposeful, and aligned with physical intuition.

Why This Is Best Practice

Adopted by: Apple iOS Human Interface Guidelines, Google Material Design, Disney Feature Animation studios Impact: Correct easing reduces perceived animation duration by 20% and increases user-rated "naturalness" scores by 35% vs linear motion (Material Design research 2016) Why best: Disney's slow-in/slow-out principle (ease-in-out) mirrors physical reality — objects accelerate and decelerate. Linear motion reads as robotic. Matching easing to interaction type communicates intent.

Sources: Thomas & Johnston (1981) Chapter 4; Lasseter SIGGRAPH (1987); Google Material Design motion guidelines

Steps

1. Identify animation intent — categorize as: entrance, exit, emphasis, state-change, or path-follow. Intent determines easing family.
2. Select easing family — entrance → ease-out (fast start, soft landing); exit → ease-in (slow start, fast exit); emphasis → spring or ease-in-out; path-follow → linear or custom cubic-bezier.
3. Choose duration tier — micro (50–100ms): hover, toggle; standard (150–250ms): show/hide, expand; complex (300–500ms): panel slide, modal; page (400–700ms): route transition.
4. Adjust for element size — larger elements need ~20% longer duration; small badges use micro tier even for complex state changes.
5. Adjust for distance — elements traveling >50% of screen need proportionally longer duration; use the formula: duration = base_duration × (travel_distance / reference_distance)^0.5.
6. Validate the curve visually — use browser DevTools animation inspector or cubic-bezier.com to preview; test at 25% speed.
7. Test at edge cases — verify the animation reads correctly when triggered rapidly (debounce), reversed mid-play, or interrupted.
8. Apply reduced-motion alternative — replace easing transitions with instant or 100ms cross-fade for prefers-reduced-motion: reduce.

Rules

• Never use linear easing for anything perceived as physical movement — reserve for progress bars, loading spinners, and value counters.
• Ease-out (decelerate) for objects entering the screen; ease-in (accelerate) for objects leaving — mirrors physical attention patterns.
• Cap standard UI durations at 500ms; anything longer requires explicit user action (e.g., page load skeleton).
• Spring animations require defined stiffness, damping, and mass — avoid spring for exit animations where overshooting creates visual noise.
• Cubic-bezier values must be tested on actual target hardware; desktop Chrome ≠ low-end Android.

Common Mistakes

• Using ease-in for entrances — elements feel like they slam into place; user attention is not drawn smoothly.
• Using the same duration for all elements in a sequence — removes sense of hierarchy; stagger and vary duration to guide eye.
• Ignoring frame rate constraints — 300ms animation on 60fps = 18 frames; on 30fps = 9 frames; design for the minimum target FPS.
• Overusing spring for emphasis — excessive bounce cheapens brand feel; reserve spring for explicit delight moments (success states, achievements).
• Timing based on "feels right" in Figma — prototype tools run at variable FPS; always validate timing in production runtime.

When NOT to Use

• Static content with no state changes (no animation needed at all)
• Animations controlled by physics engines — let the engine own timing
• Real-time data visualizations where animation must match data rate