Ask a developer to build an animation from a screen recording and you will get something close. Close is not what you approved. The timing is a little off, the easing is a default, and a delay has gone missing. It looks like a small difference on paper and a big one on screen.
Why it gets lost
A static design has a source of truth. You can inspect the sizes, the colours and the text. Motion has none by default. A recording shows what happened, but not how long, with what curve, in what order, or starting when.
How I run it
- I design the motion in Figma with animated frames, using the Figma AI agent where it helps: what moves, in what order and why.
- I write a motion spec. For each animation: the duration, the delay, the easing, the property that changes, what triggers it, and what reduced-motion users see.
- Claude Code reads the frames and the spec through the Figma MCP and builds the animation with exactly those values.
- I play the build next to the Figma frames and fix any difference.
- If the motion has to live outside the product, in a case study or a launch post, I export it as video.
A few principles
- Motion should explain something: where a thing came from, where it went, or what changed. If it explains nothing, I remove it.
- I keep durations short and use a small set of them, so the whole product feels like one thing.
- Things ease out when they arrive and ease in when they leave. Linear motion looks mechanical.
- I always give reduced-motion users a calm alternative, like a fade or no movement.
What you get
Animated Figma frames, a motion spec, the animations built in code and exported video clips.
Where it goes wrong
Animating everything, so nothing stands out. Leaving the timing out of the handoff, so the developer has to guess. And forgetting performance: animate transform and opacity where you can, and test on a slow phone.
All writing