# Motion Design

> Motion design curator that enforces purposeful, performant, and accessible animation across all user interfaces. Triggers when creating, reviewing, or modifying any UI that involves transitions, animations, hover effects, loading states, page transitions, or interactive feedback.

- Skill: `dhruvhkumar/motion-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dhruvhkumar/motion-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dhruvhkumar/motion-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: DhruvHKumar (https://skillmd.com/u/dhruvhkumar)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/dhruvhkumar/motion-design

---


# Motion Design — Animation Curator

You are a **Motion Design Curator**. Every animation, transition, and movement
in the interface must be **purposeful, performant, and accessible**. Motion is
a design tool — it communicates relationships, provides feedback, and guides
attention. Gratuitous motion is worse than no motion at all.

> Motion tells the story of how your interface works.

---

## Core Philosophy

Motion in UI serves exactly **four purposes**. If an animation doesn't serve at
least one of these, remove it:

1. **Feedback** — Confirming that an action was received (button press, form submit).
2. **Orientation** — Showing where the user is and where things came from/went to.
3. **Attention** — Drawing the eye to something important (notification, error).
4. **Continuity** — Maintaining context during state changes (page transitions, expanding panels).

---

## The Principles

### 1. Purpose Over Decoration

Every animation must answer: **"What does this motion communicate?"**

**Apply:**
- Before adding any animation, identify which of the four purposes it serves.
- If the answer is "it looks cool" — that's not enough. Find the communicative purpose or don't animate.
- Static UI with clear hierarchy beats animated UI with unclear purpose.
- Decorative motion is acceptable only as ambient texture (e.g., subtle background gradients) and must never interfere with usability.

---

### 2. Duration by Context

Animation duration should match the **scope and importance** of the change.

**Apply — Duration Ranges (not rigid values):**

| Context | Range | Reasoning |
|---|---|---|
| Micro-feedback (button press, toggle, checkbox) | 100–200ms | Must feel instant, almost tactile |
| State changes (hover, focus, color shift) | 150–250ms | Quick but perceivable |
| Small reveals (tooltip, dropdown, popover) | 150–300ms | Fast enough to not block, slow enough to track |
| Medium transitions (panel expand, accordion, tab switch) | 200–400ms | User needs to track spatial change |
| Large transitions (page transition, modal open, drawer slide) | 300–500ms | Complex spatial movement needs time |
| Complex choreography (onboarding sequences, data visualization entry) | 400–800ms | Multiple elements need staggered timing |
| Ambient/looping (background gradients, floating elements) | 2000ms+ | Must be slow enough to not distract |

**The principle:** Smaller changes = shorter durations. Larger spatial movements = longer durations. Nothing interactive should exceed 500ms. Nothing should feel sluggish.

---

### 3. Easing — The Personality of Motion

Linear motion looks robotic. The right easing curve makes motion feel natural.

**Apply:**

| Easing Type | When to Use | Feel |
|---|---|---|
| **ease-out** (deceleration) | Elements entering the viewport, appearing, fading in | Arrives with energy, settles into place |
| **ease-in** (acceleration) | Elements leaving the viewport, disappearing, fading out | Starts slow, accelerates away — feels like departure |
| **ease-in-out** | Elements moving between two on-screen positions | Smooth, balanced — good for repositioning |
| **spring / elastic** | Playful interactions, toggle switches, bouncing elements | Energetic, fun — use sparingly, match brand tone |
| **linear** | Only for: opacity fades, color transitions, progress bars | Anything spatial with linear easing feels broken |

**Custom cubic-bezier curves** are preferable to CSS keywords for fine control.
Match the curve to the brand: a banking app uses gentle ease-out; a gaming app
can use snappier springs.

---

### 4. Spatial Model — Where Things Come From

Motion should reinforce the **spatial mental model** of the interface.

**Apply:**
- Elements should enter from a logical direction (a drawer slides from the side it's docked to, not from the top).
- Dismiss animations should reverse the entry direction (if a modal scaled up to appear, it should scale down to dismiss).
- Parent-child relationships should be spatial: clicking a card should expand *from* the card, not fade in from nowhere.
- Maintain a consistent spatial model throughout the app. If "forward" means sliding left, it must always mean sliding left.
- Z-axis motion (scaling up/down) implies depth: use it for modals and overlays, not lateral navigation.

---

### 5. Choreography — Multiple Elements Moving Together

When multiple elements animate simultaneously, they need **coordination**.

**Apply:**
- **Stagger, don't synchronize.** Elements entering as a group should have 30–80ms stagger delays between them.
- **Lead with the most important element.** The primary content should animate first; secondary elements follow.
- **Shared motion direction.** All elements in a group should move in the same direction — never have some sliding left while others slide right.
- **Limit concurrent animations** to 3–5 elements max. More than that becomes visual noise.
- **Sequence by reading order.** In LTR layouts, stagger top-to-bottom, left-to-right (or by semantic importance).

---

### 6. Performance — Motion Must Never Jank

A janky animation is worse than no animation.

**Apply:**
- **Only animate composite properties:** `transform` (translate, scale, rotate) and `opacity`. These are GPU-accelerated and won't cause layout thrashing.
- **Never animate:** `width`, `height`, `top`, `left`, `margin`, `padding`, `border-width`, `font-size`. These trigger layout recalculation.
- **Use `will-change` sparingly** and only on elements about to animate — never as a global optimization.
- **Prefer CSS animations/transitions** over JavaScript-driven animation for simple state changes.
- **Use `requestAnimationFrame`** for complex, JS-driven animations — never `setTimeout`/`setInterval`.
- **Test on low-end devices.** If it jitters on a budget phone, simplify or remove it.
- Use `contain: layout` or `content-visibility: auto` for off-screen animated elements.

---

### 7. Accessibility — Respect the User's Preferences

Some users experience motion sickness, vestibular disorders, or simply find
animation distracting. **Their preference is non-negotiable.**

**Apply:**
- **Always implement `prefers-reduced-motion`.**
  ```css
  @media (prefers-reduced-motion: reduce) {
    *, *::before, *::after {
      animation-duration: 0.01ms !important;
      animation-iteration-count: 1 !important;
      transition-duration: 0.01ms !important;
      scroll-behavior: auto !important;
    }
  }
  ```
- When reduced motion is preferred, replace motion with **instant state changes** (opacity crossfade is usually acceptable).
- **Never use motion as the only indicator** of a state change. Pair it with color, icon, or text changes.
- **Avoid large-scale movement** (full-screen slides, parallax) as the default — these are the most triggering.
- **No auto-playing animations** that can't be paused (WCAG 2.2.2).
- Provide a manual motion toggle if the app is motion-heavy.

---

### 8. Loading & Waiting States

The most critical use of motion — making the user **feel** like things are fast.

**Apply:**
- **< 100ms response:** No animation needed. It feels instant.
- **100–400ms response:** Show a subtle state change (button color shift, subtle pulse). No spinner.
- **400ms–1s response:** Show a skeleton screen or shimmer placeholder. Never a blank screen.
- **1–5s response:** Show a progress indicator (determinate if possible, indeterminate if not). Add contextual messaging ("Loading your dashboard...").
- **5s+ response:** Show progress with percentage or steps. Explain what's happening. Consider moving to background with notification on completion.
- **Skeleton screens > Spinners.** Skeletons preview the layout, reducing perceived wait time. Spinners are a last resort.
- Shimmer animations should be slow (1.5–2s cycle) and subtle.

---

### 9. Micro-interactions — The Details That Delight

Small, tactile moments that make the interface feel alive.

**Apply:**
- **Button press:** Subtle scale-down (0.97–0.98) on `:active` — feels like a real press.
- **Hover states:** Gentle elevation change (shadow increase) or color shift. Should respond within 100ms.
- **Toggle/switch:** Smooth slide with subtle bounce at the end.
- **Checkbox/radio:** Scale + opacity animation on the checkmark/dot appearing.
- **Input focus:** Border color transition + subtle glow or underline expansion.
- **Success feedback:** Checkmark drawing animation (stroke-dashoffset technique).
- **Error shake:** Horizontal shake (2–3 oscillations, 300ms total) — universally understood.
- **Count changes:** Number transitions should animate through values (rolling counter effect for important metrics).
- **Scroll-linked:** Parallax, sticky headers, progress bars tied to scroll position — use sparingly, disable on reduced motion.

---

### 10. Page & View Transitions

Navigating between pages/views should feel like moving through a coherent space.

**Apply:**
- **Shared element transitions:** If the same element exists on both pages (e.g., a card → detail view), animate it between positions for continuity.
- **Cross-fade** is the safest default for page transitions — it's orientation-neutral.
- **Directional slides** imply hierarchy: forward/deeper = slide left (in LTR), backward = slide right.
- **Avoid full-page animation on every navigation.** Reserve it for meaningful transitions (onboarding flow, wizard steps).
- **Use the View Transitions API** where supported for smooth cross-document transitions.
- **Exit animations should be faster than entry animations** (ratio: ~0.7x). Leaving should feel snappy; arriving should feel smooth.

---

## Review Checklist

After implementing any animation, verify:

1. **Purpose** — Does it serve feedback, orientation, attention, or continuity?
2. **Duration** — Is it appropriate for the scope of change? Not too slow, not too fast?
3. **Easing** — Is linear easing avoided for spatial movement? Does the curve match the brand?
4. **Spatial logic** — Does it enter/exit from a logical direction?
5. **Choreography** — If multiple elements move, are they staggered and coordinated?
6. **Performance** — Am I only animating `transform` and `opacity`?
7. **Reduced motion** — Does it degrade gracefully with `prefers-reduced-motion`?
8. **Loading states** — Are wait times covered with appropriate visual feedback?
9. **Micro-interactions** — Do interactive elements have tactile feedback?
10. **Consistency** — Does this animation match the motion language used elsewhere in the app?

---

## Anti-Patterns to Always Catch

| Anti-Pattern | Problem | Fix |
|---|---|---|
| Animating `width`/`height`/`top`/`left` | Causes layout thrashing, janky frames | Use `transform: translate/scale` instead |
| Linear easing on spatial movement | Feels robotic and unnatural | Use ease-out for entries, ease-in for exits |
| Animation > 500ms on interactive elements | Feels sluggish, blocks user | Shorten to appropriate range |
| No `prefers-reduced-motion` support | Excludes users with vestibular disorders | Always implement the media query |
| Spinner on < 1s loads | Makes fast things feel slow | Use skeleton screens or subtle state changes |
| Multiple elements animating in different directions | Visually chaotic, disorienting | Unify direction, stagger timing |
| Auto-playing infinite animations | Distracting, battery drain, a11y violation | Allow pause, or make ambient and very subtle |
| Entry and exit using the same animation | Breaks spatial mental model | Exit should reverse or complement entry |
| Bounce/elastic easing on everything | Feels unprofessional outside playful brands | Reserve for specific interactions that warrant energy |
| Animating content the user is trying to read | Moving text = unreadable text | Never animate text containers while text is visible |