# Skill: Specify purposeful, accessible UI animations that help rather than annoy

> When adding motion to a web interface, define what each animation communicates and constrain duration, properties, and accessibility before writing any animation code. Applies when asking an AI to animate a landing page, component, or transition.

Source: sodigi·learn — vibecoding/animacii-pomogayut · https://sodigi.io/learn/vibecoding/animacii-pomogayut

## When to use
- You are about to ask AI to "add animations" or "make it look nicer" with no further constraints.
- A site is stuttering or lagging during animations.
- You need to add scroll-triggered appearances, loading states, or interactive feedback.
- You want to ensure the site respects the OS-level reduce-motion accessibility setting.

## Core rules
- Every animation must have exactly one job: lead the eye, explain a state (loading/success/error), or preserve the link between screens. No job -- cut it.
- Fast is better: button press ~0.15s, block appearance ~0.35s, large transition ~0.6s max. Anything over 1s is almost always a mistake.
- Animate only compositor-friendly properties: opacity and transform (shift/scale). Never animate width, height, top, left, margin, padding -- those trigger layout recalculation and cause stutter.
- Always include a reduce-motion mode: in that mode, keep only gentle fade-in, remove all position flying.
- Less motion is better. When every element moves, attention latches onto nothing.
- Delay between list items appearing must be tiny; a queue that takes half a second per row is infuriating.

## Procedure
1. Identify which elements actually need animation and what job each one does (lead eye / explain state / preserve link). List them explicitly.
2. Decide duration for each: press reaction ~0.15s, appearance ~0.35s, full-screen transition ~0.6s.
3. Specify CSS properties: opacity + transform only. Flag any existing animations using width/height for replacement.
4. Define interactive states: button hover (slight scale/opacity shift), active (slightly pressed), focus visible.
5. Add reduce-motion media query: `@media (prefers-reduced-motion: reduce)` removes position motion, keeps only fade-in.
6. Review the result against the checklist: does every animation have a job, is everything under 1s, does reduce-motion work?

## Ready-to-use prompt
```
Add animations to this interface following these rules -- not for visual decoration.

1. Animate only opacity and a slight transform shift. Never animate width or height: those cause stutter.
2. Durations: button press ~0.15s, blocks appearing ~0.35s. Nothing longer than 0.6s.
3. Buttons respond subtly to hover and press (small scale or opacity change only, no jumping).
4. Scroll-triggered blocks fade in gently. List items appear fast with no long sequential queue.
5. Respect the system reduce-motion setting: in that mode keep only fade-in, remove all positional flying.
6. Every animation must mean something: loading, success, error, or a transition. If it explains nothing -- remove it.
```

## Pitfalls
- Telling AI "make it pretty with animations" with no constraints -- it will pile on all effects it has seen.
- Making animations slow "so the user can see them" -- slow motion reads as lag, not beauty.
- Animating width or height -- always causes stutter; switch to transform + opacity.
- Adding endless decorative animations (pulsing backgrounds, infinite loops) -- they steal attention without communicating anything.
- A list that slides in one row at a time with a long gap per row -- infuriating on any device.
- Forgetting reduce-motion -- some users genuinely experience nausea from on-screen motion.
- Animating every element -- when everything moves, nothing is prioritized.