Why you are animating more often than you should.
Summary
Motion can make an interface feel faster, more predictable and more enjoyable, or it can do the exact opposite and cost you the user's trust. Emil's first test is purpose. If you cannot say in one sentence what an animation is for, it should not be there. His second test is frequency, and it is the one most people skip. Raycast opens hundreds of times a day and has no open animation at all, which is the correct decision. Delight is for the things people meet rarely.
View full writingGoes well with
emil-design-eng
The design-engineering house style behind Sonner and Vaul.
Emil's main skill. Mostly animation, with the UI-polish and component judgement that surrounds it: what to build, how far to push it, and when to stop.
npx skills add https://github.com/emilkowalski/skills
animate
Builds an animation from scratch, decisions in the order that matters.
Should it animate at all, what purpose, which tool, which properties, which curve and duration, how it interrupts, how it exits. Then writes the implementation.
npx skills add https://github.com/emilkowalski/skills --skill animate
review-animations
Reviews your motion strictly, against Emil's rules.
A production-critical pass over animation quality, timing and consistency in a diff. Pairs with improve-animations, which does the same for a whole codebase.
npx skills add https://github.com/emilkowalski/skills --skill review-animations