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