# How the Animation Decision Framework Decides What to Animate: A Complete Guide

> Discover how the Animation Decision Framework decides what to animate using its seven-step checklist for optimal UI performance. Learn its purpose, frequency, duration, and more.

- Repository: [Emil Kowalski/skills](https://github.com/emilkowalski/skills)
- Tags: how-to-guide
- Published: 2026-08-06

---

**The Animation Decision Framework evaluates every potential UI animation through a deterministic seven-step checklist—purpose, frequency, duration budget, easing, accessibility, and implementation choice—to arrive at a binary animate-or-don't-animate verdict.**

The **Animation Decision Framework** is a lightweight, principle-driven system documented in [emilkowalski/skills](https://github.com/emilkowalski/skills) that helps design engineering teams make consistent, defensible choices about UI motion. Rather than relying on subjective preferences, the framework applies sequential criteria to determine whether an animation deserves to exist and, if so, how it should be built.

## The Seven Decision Steps in the Animation Decision Framework

The framework processes each animation candidate through the following checks, in order. Failing any step typically results in deletion or reduction of the animation.

### Purpose: Why Does This Animate?

Every animation must serve a **functional reason**, not merely aesthetic appeal. The framework recognizes five valid purposes:

- **Spatial consistency** — maintaining context during view changes
- **State indication** — showing that something has changed
- **Feedback** — confirming user action
- **Explanation** — clarifying cause-effect relationships
- **Preventing jarring visual change** — smoothing transitions

Purely decorative animations ("it looks cool") are rejected. This check appears in [[`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md)](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md).

### Frequency: How Often Will Users See It?

The framework maps usage frequency directly to animation treatment:

| Frequency | Treatment | Example |
|-----------|-----------|---------|
| **≥ 100 times/day** | **No animation, ever** | Keyboard shortcuts, command palette toggles |
| **Tens of times/day** | **Reduced-motion** | Navigation elements |
| **Occasional** | **Standard animation** | Modals, drawers, toasts |
| **Rare/first-time** | **Delightful animation** allowed | Onboarding, celebratory moments |

High-frequency interactions must be instant. Animation becomes a penalty when users encounter it hundreds of times daily.

### Duration Budget: Is It Fast Enough?

UI animations must stay **under 300 ms**. Anything slower requires strong justification or is flagged as a violation. This hard limit is documented in [[`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md)](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md).

The 300 ms threshold balances perceptible motion with minimal interruption to user flow.

### Easing: Which Curve to Use?

The framework prohibits `ease-in` for UI animations—it feels sluggish and unresponsive. Preferred options:

- **`ease-out`** — decelerating motion feels responsive
- **Custom-crafted curves** — e.g., `cubic-bezier(0.22, 1, 0.36, 1)`
- **Spring-based motion** — for interactive, physically plausible feedback

Easing guidance appears in [[`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md)](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md).

### Accessibility: Does It Respect Reduced Motion?

The framework mandates:

- Honor `prefers-reduced-motion` media query
- Keep **opacity and color transitions** for users who need reduced motion
- Drop **positional movement** when reduced motion is preferred
- Gate hover effects behind `@media (hover: hover) and (pointer: fine)`

### Implementation Choice: CSS vs. JS

Technical implementation follows functional requirements:

| Use Case | Recommended Approach |
|----------|-------------------|
| Interruptible/retargetable animations (toggles, toasts) | **CSS transitions** |
| Predetermined, non-interruptible motion | **Keyframe animations** or **JS-based springs** |

This guidance appears in [[`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md)](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md).

### Overall Verdict: Keep, Reduce, or Delete

The final step applies binary judgment. As documented in [[`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md)](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md), animations that fail any check should be **deleted** or **reduced**. Only animations passing all criteria are approved for implementation.

## Applying the Animation Decision Framework in Practice

Below are illustrative code patterns showing how developers operationalize the framework's criteria.

### React Component Example

```tsx
function AnimatedButton({ label }: { label: string }) {
  // 1️⃣ Purpose: state indication for panel toggle
  const purpose = "state indication";

  // 2️⃣ Frequency: occasional (panel toggling) → standard animation
  const frequency = "occasional";

  // 3️⃣ Duration: under 300 ms budget
  const duration = 200;

  // 4️⃣ Easing: custom ease-out curve
  const easing = "cubic-bezier(0.22, 1, 0.36, 1)";

  // 5️⃣ Accessibility: respect reduced-motion preference
  const prefersReduced = useReducedMotion();

  const style = prefersReduced
    ? { transition: "none" }
    : {
        transition: `transform ${duration}ms ${easing}`,
        transform: "scale(1.05)",
      };

  return (
    <button style={style} onMouseDown={() => {/* toggle panel */}}>
      {label}
    </button>
  );
}

```

### CSS-Only Implementation

```css
/* Toast animation: occasional use, <300 ms duration */
.toast {
  opacity: 0;
  transform: translateY(8px);
  animation: fadeIn 250ms ease-out forwards;
}

@keyframes fadeIn {
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

/* Reduced-motion fallback */
@media (prefers-reduced-motion: reduce) {
  .toast {
    animation: none;
    opacity: 1;
    transform: none;
  }
}

```

## Key Source Files in the Animation Decision Framework

| File | Role |
|------|------|
| [[`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md)](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md) | Core review process and criteria definition |
| [[`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md)](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md) | Duration budgets and technical implementation rules |
| [[`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md)](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md) | Auditing methodology and verdict application |
| [[`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md)](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) | Philosophical foundation and detailed rationale |
| [[`skills/find-animation-opportunities/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/find-animation-opportunities/SKILL.md)](https://github.com/emilkowalski/skills/blob/main/skills/find-animation-opportunities/SKILL.md) | Discovering new animations using the same logic |

## Summary

- The **Animation Decision Framework** applies seven sequential checks to every UI animation candidate: **purpose → frequency → duration → easing → accessibility → implementation → verdict**
- **Decorative animations are rejected**; only functional motion with clear user benefit passes
- **High-frequency interactions (≥100×/day) get no animation**; rare interactions may receive delightful treatment
- The **300 ms duration budget** is non-negotiable without explicit justification
- **CSS transitions** are preferred for interruptible animations; **JS springs** for predetermined motion
- All decisions must honor **`prefers-reduced-motion`** and pointer capability media queries

## Frequently Asked Questions

### What happens if an animation fails just one step of the framework?

The framework recommends **deleting the animation entirely** or **reducing its scope** until it passes all criteria. As documented in [[`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md)](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md), partial compliance is treated as non-compliance. The binary verdict ensures consistent, defensible outcomes across teams.

### Why does the framework ban `ease-in` easing curves?

`ease-in` curves start slow and accelerate, creating perceived lag between user action and system response. The framework mandates `ease-out` or custom curves that start quickly and decelerate, matching user expectations of immediate feedback. This principle appears in [[`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md)](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md).

### How does the framework handle animations for power users versus first-time users?

The **frequency criterion** creates differentiated treatment. Power users encountering an action hundreds of times daily receive **no animation**, while first-time or rare-use interactions may qualify for **delightful, more elaborate motion**. This prevents animation fatigue without sacrificing educational or celebratory moments.

### Can the Animation Decision Framework be applied to existing codebases?

Yes. [[`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md)](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md) documents a systematic audit process: inventory existing animations, apply the seven-step checklist to each, and generate actionable findings of violations to fix or animations to remove. The deterministic criteria make audits repeatable across team members.