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

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 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).

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).

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).

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).

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), 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

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

/* 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)	Core review process and criteria definition
[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)	Auditing methodology and verdict application
[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)	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), 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).

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) 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}