Figma Motion brought real timeline animation into the design tool, which means the everyday UI animation you used to leave for After Effects or a plugin can now happen in the file where you designed the screen. This tutorial covers how to use Figma Motion in practice: the mental model behind it, the workflow from a static frame to a finished animation, the principles that make the result feel right, and the mistakes that make it feel cheap. Because Figma Motion is a recent addition, the exact interface will keep evolving, but the workflow and the craft below hold regardless of where a button sits.
If you want the deeper argument for when to use Figma Motion versus reaching for After Effects or Rive, that decision lives in a separate comparison. This piece assumes you've decided to animate in Figma and want to do it well.
The mental model: keyframes and a timeline
Figma Motion brought real timeline animation into the design tool, which means the everyday UI animation you used to leave for After Effects or a plugin can now happen in the file where you designed the screen.
Every timeline animation tool works on the same idea, and understanding it makes the specific tool easy to learn. You define what an element looks like at different points in time, and the tool fills in the movement between those points. Each of those defined points is a keyframe. Two keyframes, a start and an end, plus the tool interpolating between them, is the atom of all animation.
So the whole job breaks into three decisions: what changes (position, size, opacity, rotation, color), over how long (the duration between keyframes), and how it moves between the two states (the easing or spring that shapes the speed). Get comfortable thinking in those three terms and Figma Motion stops being a new interface to memorize and becomes a place to apply what you already understand about motion. Figma Design gives you exactly the controls for it: a timeline with keyframes, ready-made presets, adjustable easing curves, and spring physics.
The workflow, stage by stage
Here's the path from a static design to a finished animation, described as stages rather than clicks, so it holds even as the interface evolves.
Stage 1: design the end states first. Before animating anything, have the states you're animating between as actual design. If you're animating a card expanding into a detail view, design the collapsed card and the expanded view as real frames. Animation connects states; it can't invent them. Most animation problems are actually design problems in disguise, two states that don't relate cleanly, so getting the states right first saves you from animating your way around a bad transition.
Stage 2: set your keyframes. Place a keyframe at the start state and one at the end state. This tells Figma Motion what's changing and gives it two points to interpolate between. Start with the obvious properties, position and opacity for something entering, size and position for something expanding.
Stage 3: set the duration. Decide how long the motion takes. For most UI, that's short, roughly 200 to 300 milliseconds for a standard transition, faster for small microinteractions. Err on the quick side; a motion that's slightly too fast reads as responsive, while one that's slightly too slow makes the whole interface feel heavy.
Stage 4: shape the movement with easing. This is the step that separates animation that feels right from animation that feels robotic. Apply an ease-out for something entering or settling, an ease-in for something leaving, or a spring for anything interactive. Never leave motion linear, because nothing in the physical world moves at a constant speed, and linear motion is the single most common reason an animation feels cheap. The full craft of easing and timing is worth studying on its own; the short version is: match the curve to whether the thing is arriving, leaving, or moving.
Stage 5: refine and test. Play it back, and be honest about whether it feels right. Motion that looked fine as a plan often feels too slow, too bouncy, or slightly off on playback. Adjust the duration and easing until it disappears into feeling natural, which is exactly what good UI motion should do.
Build one: a simple entrance
Walk the workflow on the simplest real case, an element fading and sliding into place.
Conceptually, the entrance is two keyframes: the element starts slightly below its final position and fully transparent, and ends at its resting position and fully opaque, over about 250 milliseconds, with an ease-out so it arrives quickly and settles. That combination, a short slide up plus a fade in, on an ease-out, is the workhorse entrance you'll reuse constantly, and it reads as responsive because the motion is fastest right after it begins.
Build two: a springy microinteraction
The second build shows where springs earn their place, on something interactive.
Conceptually, a microinteraction like a button press benefits from a spring rather than a fixed curve, because the slight overshoot and settle read as physical responsiveness. The key is restraint: a small overshoot adds life, while too much reads as unserious and wobbly, so tune the spring until the settle feels confident. Figma Motion includes spring physics for exactly this kind of interactive motion. Microinteractions like this are where motion does the most work for the least screen time, and they're covered as patterns in microinteractions that actually convert.
Presets, and when to hand-tune
Most animation tools ship presets, ready-made combinations of duration and easing you can apply in one step, and Figma Motion is no exception; it offers preset animations alongside the timeline for building from scratch.
Presets are the right starting point for common motions, because they encode reasonable defaults and save you from setting everything by hand. Use them for standard entrances, exits, and transitions. Hand-tune when the preset feels slightly off for your specific case, or when you're building a signature interaction that should feel particular to your product rather than generic. A good habit is to start from a preset and adjust, rather than either accepting the preset blindly or building from scratch every time. Better still, define a small, consistent set of durations and curves your whole product reuses, so motion feels like one system instead of a dozen individual instincts.
Common mistakes
The mistakes that make Figma Motion output feel amateur are consistent and easy to avoid once named.
Linear motion. Leaving easing off is the top offender; it makes everything feel mechanical. Always shape the movement.
Too slow. New animators tend to make motion too long because it looks more visible, but slow motion makes an interface feel sluggish. Keep UI motion short.
Animating too much. Because the tool makes animation easy, the temptation is to animate everything, which produces a busy, exhausting interface. The best motion is often the motion you barely notice; animate to communicate, guide attention, or give feedback, not to show that you can. This restraint is the heart of treating motion as craft.
Ignoring reduced motion. Some users have vestibular conditions that make large or bouncy motion physically unpleasant. Any animation that ships needs a reduced-motion path that cuts or minimizes movement for those users. This isn't optional polish; it's the difference between motion that delights most users and motion that makes some of them unwell.
Animate components, not one-offs
The highest-leverage way to use Figma Motion is on components rather than individual instances, so an animation you build once applies everywhere that component appears. If your button's press animation lives on the component, every button in the product inherits it, which keeps motion consistent and saves you rebuilding the same interaction repeatedly. This is the same logic that makes a component library valuable, extended to motion: define the behavior once, reuse it everywhere. It also enforces a consistent motion system, because component-level animation naturally applies the same durations and curves across the product instead of letting each screen drift toward one designer's instinct.
From Figma Motion to shipped code
Keep one reality in mind: a Figma Motion animation is design-time, which means it still has to be built in code to reach users. The animation you create is a precise specification for engineers, showing exactly what should happen, how long it takes, and how it moves, but it is not the shipped thing itself. That's genuinely useful, because a clear animated spec beats describing motion in words or a static redline, and it removes most of the ambiguity that made animation handoff painful. Just set the expectation that engineers implement it rather than paste it, the same distinction that governs all design-to-code work: the design tool shows the intent, and production requires the build. A good habit is to annotate the animation with the intended duration and easing so engineers have the exact values, not just a feel to approximate, which turns your Figma Motion work into a spec precise enough to implement faithfully.
Start Monday
Open a screen you've already designed and animate one transition in Figma Motion this week, following the five stages: design the two states, set keyframes, choose a short duration, apply an ease-out, and refine on playback. Pick something small, a menu opening, a card appearing, so you finish it. Recording that first real build, and noticing how much better it feels once you replace linear motion with an ease-out, teaches the tool faster than any amount of reading. Once the fundamentals are automatic, the harder interactions become straightforward.
Figma Motion doesn't require new talent, just the same motion principles applied in a new place, close to where your design already lives. Design your states, keyframe them, keep it short, shape the movement, and respect the users who need less of it. Do that and the animation disappears into feeling natural, which is the whole goal.