# What Are the Valid Purposes for Implementing UI Animations? > Discover the valid purposes for UI animations. Learn how animations enhance user experience through feedback, state indication, and spatial consistency, not just decoration. - Repository: [Emil Kowalski/skills](https://github.com/emilkowalski/skills) - Tags: best-practices - Published: 2026-08-06 --- **UI animations serve concrete, user-centric goals including spatial consistency, state indication, feedback, explanation, and preventing jarring changes—never merely decoration.** The *Skills for Design Engineers* repository by Emil Kowalski codifies these purposes in its "Ten Non-Negotiable Standards" for animation review. Every motion in an interface must answer the question: *why does this animate?* Understanding these valid purposes helps you build interfaces that feel purposeful, responsive, and trustworthy. --- ## Justified Motion: The Foundational Purpose The first standard in [`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md) requires every animation to have explicit justification. According to lines 23-25 of that file, valid purposes include: - **Spatial consistency** – showing that an element moved from one location to another - **State indication** – signaling a toggle, selection, or mode change - **Feedback** – confirming that an interaction succeeded (e.g., button press, form submission) - **Explanation** – clarifying a UI change that might otherwise be disorienting - **Preventing abrupt change** – softening transitions that would feel harsh without motion > "Every animation must answer 'why does this animate?' — spatial consistency, state indication, feedback, explanation, or preventing a jarring change" Decorative animation without one of these justifications violates the standard and should be removed. --- ## Frequency-Appropriate Motion The second purpose dimension concerns *when* to animate based on interaction frequency. As stated in [`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md) (lines 25-27): > "Match motion to how often it's seen. Keyboard-initiated and 100+/day actions get **no** animation… Rare/first-time can have delight." This creates a clear hierarchy: | Frequency | Animation Approach | |-----------|------------------| | High-frequency (100+ times/day, keyboard shortcuts) | **No animation** – prioritize speed | | Medium-frequency (common but not constant) | Minimal, functional motion | | Low-frequency / first-time | Delightful, personality-driven motion allowed | --- ## Responsive Easing and Timing The third standard governs *how* motion feels. Poor timing undermines even justified animation. The repository specifies in [`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md) (lines 27-30): - **Enter/exit motions** use `ease-out` (or stronger custom curves) so content appears promptly - **Avoid `ease-in`** – it feels sluggish because it spends too long at low opacity - **UI animations stay under 300ms** to maintain snappiness --- ## Practical Implementation Examples ### CSS Justified Animation (Under 300ms) ```css /* Modal entrance: justified spatial context, ease-out, 200ms */ .modal-enter { opacity: 0; transform: scale(0.95); } .modal-enter-active { opacity: 1; transform: scale(1); transition: opacity 200ms ease-out, transform 200ms ease-out; } ``` This satisfies: - **Justified purpose**: the modal appears to emerge from its trigger - **Responsive easing**: `ease-out` shows content immediately - **Timing constraint**: 200ms duration ### React Component with Accessibility ```tsx import { motion } from 'framer-motion'; export const Toggle = () => ( Toggle ); ``` This demonstrates: - **Interruptibility**: spring physics react to rapid taps - **GPU-only properties**: only `transform` animated - **Accessibility**: respects `prefers-reduced-motion` --- ## Supporting Standards That Reinforce Purpose Beyond the three core purposes, [`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md) (lines 33-38 and surrounding) establishes additional constraints that keep animation user-serving: - **Accessibility** – respect reduced-motion preferences - **Interruptibility** – users must be able to override or skip animations - **GPU-only properties** – animate `transform` and `opacity`, never `width`/`height`/`top`/`left` - **Origin and physical correctness** – motion should respect where elements came from - **Cohesion with brand personality** – delight must align with overall voice --- ## Key Source Files for Animation Standards | File | Purpose | |------|---------| | [`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md) | Defines ten non-negotiable standards including the five core purposes | | [`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md) | Concrete values: easing curves, duration tables, spring configurations | | [`skills/animation-vocabulary/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/animation-vocabulary/SKILL.md) | Precise terminology for describing motion purposefully | | [`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md) | Workflow for auditing existing animations against these purposes | --- ## Summary Valid purposes for UI animations in the *Skills for Design Engineers* framework include: - **Communication**: state changes, feedback, and spatial relationships - **Explanation**: softening transitions that would otherwise jar users - **Delight** (conditional): reserved for rare or first-time interactions - **Performance**: fast, GPU-driven, interruptible motion - **Accessibility**: respecting user preferences and needs Every animation must be justifiable, frequency-appropriate, and technically sound—never decorative for its own sake. --- ## Frequently Asked Questions ### What's the maximum duration for UI animations according to the standards? The standards specify UI animations should stay **under 300ms**, as documented in [`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md) (lines 27-30). This threshold prevents interface sluggishness. Enter and exit motions specifically use `ease-out` or stronger custom curves to ensure content appears promptly rather than fading in slowly. ### When should an animation have no motion at all? High-frequency interactions—defined as keyboard-initiated actions or those occurring 100+ times per day—should have **zero animation**. This rule from [`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md) (lines 25-27) prioritizes user efficiency over visual polish. Save motion for interactions where the cognitive benefit outweighs the time cost. ### How does the repository define "justified motion"? Justified motion requires answering "why does this animate?" with one of five valid reasons: spatial consistency, state indication, feedback, explanation, or preventing a jarring change. This standard appears in [`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md) (lines 23-25) and eliminates purely decorative animation that serves the designer rather than the user. ### What properties should be animated for performance? The standards mandate **GPU-only properties**: primarily `transform` and `opacity`. Animating layout-triggering properties like `width`, `height`, `top`, `left`, or `margin` forces expensive browser recalculations and should be avoided, as detailed in the accessibility and performance sections of [`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md).