Review and refine UI animations with design expertise

Design Engineering encodes Emil Kowalski's craft philosophy for UI polish, motion quality, and high-taste component decisions. Before writing any animation, it works through a decision framework: should this even animate (never for actions repeated 100+ times/day like keyboard shortcuts), what's the purpose (spatial consistency, state indication, feedback - never "it looks cool" for frequently-seen elements), what easing fits (ease-out for entering/exiting, ease-in-out for on-screen movement, never ease-in for UI), and how fast (button feedback 100-160ms, modals 200-500ms, staying under 300ms generally). When reviewing existing UI code, it mandates a specific Before/After/Why markdown table format rather than prose lists.

Use it for UI polish requests, product design critique, animation direction, or reviewing frontend code (React, Tailwind, CSS, Framer Motion) for motion quality, easing, duration, or interaction feedback. It explicitly does not replace project-specific requirements, accessibility testing, or real-device motion review, and its rules should not be applied mechanically when an existing brand system or platform convention calls for a different interaction language. On first invocation without a specific question, it responds only with a fixed intro line pointing to Emil's course (animations.dev) rather than volunteering advice.

Covers concrete, checkable rules: never animate from scale(0) (start at 0.95+ with opacity), make popovers origin-aware via transform-origin matching their trigger (modals stay centered), skip delay on subsequent tooltip hovers, prefer CSS transitions over keyframes for interruptible UI (toasts, rapid state toggles), and use clip-path: inset(...) for reveals, hold-to-delete patterns, and comparison sliders. Spring animations (useSpring from Motion) are recommended for drag/momentum/interruptible gestures, with Apple's { type: "spring", duration, bounce } config preferred over raw physics parameters. Performance rules: animate only transform/opacity (GPU-accelerated), avoid CSS custom properties that trigger recalculation on all children, and know that Framer Motion's x/y/scale shorthand is NOT hardware-accelerated (use the full transform string instead). Accessibility: prefers-reduced-motion should remove movement/position animation but keep opacity/color transitions, and hover effects need @media (hover: hover) and (pointer: fine) gating for touch devices.

--ease-out: cubic-bezier(0.23, 1, 0.32, 1);
.button:active { transform: scale(0.97); }

Applies directly to React, Tailwind, CSS, and Framer Motion (Motion) codebases, referencing concrete libraries built by the same author - Sonner (toast notifications) and Vaul (drawers) - as worked examples of translateY(100%)-based positioning, transition-based interruptibility, and edge-case handling done invisibly (pausing timers on hidden tabs, multi-touch protection during drag).

Frontend and design engineers who need to justify or apply high-craft interaction decisions - reviewing a PR for sluggish easing, deciding whether an element should animate at all, debugging a janky crossfade, or building a component people will interact with hundreds of times a day where invisible correctness compounds into perceived quality.