/design-motion

name: design-motion
description: "Use when adding or reviewing motion on an already-settled layout or component — never to hide or compensate for an unfinished one."
when-to-use: "After the static body/component exists (design-web/design-webapp/design-ios/design-android) and motion is being added or reviewed — never to hide an unfinished layout."
keywords: motion, animation, easing, duration, transform, opacity, reduced-motion, ai-slop
priority: high
related: design-web, design-webapp, design-review, design-system

<objective> A motion pass applied on top of an already-settled layout: the animation-decision gate (should this even animate, what's its purpose, what easing, what duration), transform/opacity-first materials, the 100/300/500ms duration scale, exponential/emphasized easing curves (bounce and elastic are banned outright), and the mandatory `prefers-reduced-motion` fallback shipped in the same pass.

Also enforces the ban on the AI motion signature (`opacity:0 + translateY(20px) + ease-in-out` applied uniformly to every entrance).

Runs only after the static body/component exists (`design-web`, `design-webapp`, `design-ios`, `design-android`) — never used to hide or compensate for an unfinished layout. </objective>

Design Motion — Timing, Easing, Materials, Restraint

When

After the static body/component exists. Motion is applied on top of a settled layout — never used to compensate for or distract from an unfinished one. Hands off to `design-review` next (Part 1 checks the reduced-motion fallback + transform/opacity discipline; Part 2's `motion-verdict.md` issues the Block/Approve).

Input

• `design-system.md` motion personality / `MOTION_INTENSITY` dial (1-10).
• The static markup/components to animate.

The animation gate — before writing any motion code

Run every candidate through `references/animation-decision-framework.md`'s 4 questions, in order: (1) should this animate at all — frequency decides, never animate keyboard-initiated or 100+/day actions; (2) what's the one-sentence purpose (spatial consistency / state indication / explanation / feedback / preventing jarring change); (3) what easing; (4) what duration. Most "let's animate this" ideas should die at question 1 — that is the point, not a formality to skip.

Materials — transform/opacity first, other properties gated

Default to `transform` and `opacity` — they skip layout and paint and run on the GPU. Animating `width`/`height`/`top`/`left`/`margin`/`padding` triggers layout+paint+composite and drops frames; see `references/motion-performance.md` for the Framer Motion shorthand caveat (`x`/`y`/`scale` shorthands are NOT hardware-accelerated, use the full `transform` string), the CSS-var recalc trap (never drive child transforms via a custom property on the parent), CSS transitions vs. keyframes for interruptible UI, and velocity-based drag dismissal (~0.11 threshold, not distance alone). Other atmospheric materials — blur, backdrop-filter, clip-path, shadow bloom, masks — are allowed when they demonstrably read as premium and stay smooth on the target viewports, verified in-browser, never a default reach; keep expensive effects bounded to small/isolated areas. `references/motion-physics.md` covers physical-correctness rules for whichever material is used: never `scale(0)`, origin-aware popovers, asymmetric enter/exit timing (exit ~75% of enter duration), staggered lists (cap total stagger time), blur masking, `@starting-style`.

Durations — the 100/300/500 rule

| Tier | Duration | Use | |---|---|---| | Micro | 100-150ms | button press, toggle, instant feedback | | State | 200-300ms | menu open, tooltip, hover states | | Layout | 300-500ms | accordion, modal, drawer | | Entrance | 500-800ms | page load, hero reveal |

Exit animations run at ~75% of the matching enter duration. Hard rule for anything that isn't a marketing/explanatory sequence: **UI feedback stays under 300ms** — a 180ms dropdown reads as more responsive than a 400ms one (`references/animation-decision-framework.md` §4).

Easing — exponential/emphasized, no bounce

Entering/exiting → `ease-out`. Moving/morphing on-screen (A→B) or state toggles → `ease-in-out`. Hover/color change → `ease`. Constant motion (marquee, progress) → `linear`. **Never `ease-in` on UI** — it delays the exact moment the user is watching most closely. Use the strong custom curves in `references/motion-tokens.md` (`--ease-out: cubic-bezier(0.23, 1, 0.32, 1)`, `--ease-in-out`, `--ease-drawer`) or the exponential/quint-out family (`cubic-bezier(0.16, 1, 0.3, 1)` and similar) — never the weak built-in CSS easings. **Bounce and elastic curves are banned outright** — they read as a toy interaction, not a premium one. Hard mechanical gate, zero tolerance: any `cubic-bezier` with a y-control-point > 1, or the literal `elastic`/`bounce` keywords, fails `design-review/references/pre-flight-checklist.md` check 9. Springs (when used — gesture-driven/interruptible motion only) keep `bounce` in **0.1-0.3**, biased toward 0.1 for dashboards/product register and up to 0.3 for playful/brand register.

Reduced motion — mandatory, not optional

Every animated deliverable ships a `prefers-reduced-motion: reduce` fallback in the same commit — never a follow-up pass. Full patterns: `references/reduced-motion.md` (global override, Framer Motion's `useReducedMotion()`/`MotionConfig`, per-animation-type disable-vs-simplify table, WCAG 2.2 SC 2.3.3/2.3.1/2.2.2). Disable spatial movement entirely (parallax, auto-playing carousels, zoom/scale transitions — vestibular risk); simplify functional feedback rather than remove it (progress bars and loading spinners stay, slowed and non-spatial; page-slide transitions become an instant swap that keeps navigation feedback). ~35% of adults over 40 are affected by vestibular disorders — this is not an edge case. `design-review` Part 1 treats a missing reduced-motion fallback as a **Critical**-severity finding (`audit-checklis