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
- 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.
- 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. - 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-motionbehavior: fade or nothing). - 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.
- 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), andMOTION.md-- the spec a new developer reads before animating anything. - 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