Motion Language Designer

# Motion Language Designer

Design motion the way type and color get designed: as a system with a scale, roles, and rules -- not per-component improvisation. Output is a motion spec plus drop-in implementation (Framer Motion variants, CSS custom properties and keyframes) so the system is enforceable, not aspirational.

## Workflow

1. **Read the brand.** From the existing product (or its design tokens and a description of the personality): is this product calm, snappy, playful, austere? Audit any existing animations -- inventory every duration, easing, and effect currently in the codebase. The spread of that inventory (14 different durations is typical) is the motivation slide.
2. **Define the scale.** Duration tokens (`instant` ~100ms for state feedback, `fast` ~180-220ms for micro-interactions, `base` ~300ms for reveals, `slow` ~500ms+ for scene changes) and an easing vocabulary (standard, decelerate for entrances, accelerate for exits, plus at most ONE signature spring/overshoot -- the personality lives here). Calibrate values to the brand read from step 1, not generic defaults.
3. **Write the choreography rules.** The part most systems skip: what animates and what never does; enter/exit asymmetry (exits faster than entrances); stagger rules (children cascade at 30-60ms, capped so long lists do not take seconds); hierarchy (one hero motion per view, everything else supports); distance rules (elements travel short distances -- 8-24px -- not across the screen); and the reduced-motion contract (every animation has a `prefers-reduced-motion` behavior: fade or nothing).
4. **Name the signature moves.** 3-5 named, reusable compositions ("card-lift", "panel-reveal", "count-up") that recur across the product and make it recognizable. Each gets a spec: trigger, properties animated, duration/easing tokens used, and when NOT to use it.
5. **Export.** `motion-tokens.json` (durations, easings, distances), `motion.css` (custom properties + keyframes + reduced-motion guards), `motion.ts` (Framer Motion variants for each signature move, referencing the tokens), and `MOTION.md` -- the spec a new developer reads before animating anything.
6. **Retrofit pass (optional).** Map the step-1 inventory onto the new system: which existing animations snap to which tokens, which are off-system and need changes, which should be deleted (motion that communicates nothing).

## Rules

- Everything animates transform and opacity; nothing animates layout properties (width, height, top) without an explicit exception logged in the spec.
- One signature easing maximum. A product where some things bounce and other things glide has two personalities.
- Motion communicates or it goes: entrances orient, feedback confirms, transitions preserve context. "It looked cool" is not a role.
- Durations come from the scale only. A 270ms one-off is drift, same as a rogue hex.
- The reduced-motion contract is not optional and not an afterthought -- it ships in the same file as every animation.
- Fast beats slow when unsure: users read 200ms as responsive and 500ms as sluggish long before they read either as beautiful.

## Quick Commands

- "Design a motion system for this product" -- full workflow
- "Audit my animations" -- step 1 inventory only
- "Just the tokens and variants" -- steps 2, 5
- "Retrofit my components" -- step 6 against an existing system