Figma Motion: Designers 🤝 Devs, finally

Since 24 June 2026 an animation in Figma lives in the same file as the design, on a timeline anyone can open, comment on and reuse. That is the change worth caring about: an animation can now be reviewed before it ships instead of argued about after. Any frame switches to Motion mode, and a developer can open the same file and copy the animation as CSS, JSON or React.

What is actually new

Motion sits alongside Design and Dev Mode as another view of the same file. Switch a frame into it and a timeline appears, where you set keyframes: a keyframe is a marked point in time with a value attached, so two keyframes on opacity mean "invisible here, visible there, work out the middle". Figma animates position, scale, rotation and opacity, and comments are time-based, so a reviewer can pin a remark to one moment instead of writing "the middle bit feels slow".

What makes this a system rather than a feature is what happens above the single frame. Animated components carry their motion the way they already carry colour and type: build the animation once and, in Figma's words, "it travels with that component across every screen and collaborator's file, the same way fill and typography do". On top sit motion variables with modes. A variable is a named value the file points at instead of a hardcoded number, and a mode is an alternative set of those values, the mechanism teams already use for light and dark themes. Define a second mode for an easing variable, switch it at page level, and every animation referencing it changes at once.

Figma's own diagnosis is unusually blunt for a launch post: "motion gets rebuilt from scratch every sprint, and what ships reflects whoever had time, not what was designed". Read it with the caveat that this is Figma describing a Figma product, and that the customer voices in the announcement were chosen by Figma. The description still fits: motion is the only part of an interface with no file that counted as the answer.

What a developer actually receives

In Dev Mode, the view Figma gives developers for inspecting a design, a Motion tab now shows the full timeline and copies the animation as CSS, JSON, or React and motion.dev. Figma claims "every timing value, easing curve, and keyframe is readable without any interpretation needed from the developer". Easing is the curve that decides how a movement accelerates and slows, and it is one of the details Figma says "get lost in translation between the file and the code". The same data comes through Figma's MCP server, the connector that hands a coding agent structured design data instead of a screenshot, which we covered when Figma measured what connected components do to generated code.

Two limits belong next to the handoff promise. Motion is in open beta, which Figma states on its handoff documentation: features may change and performance may suffer. And the handoff is the paid half: Starter accounts get limited exports, and copying animation code requires a paid plan with a Full or Dev seat.

The mode the launch never mentions

One mode matters more than any brand easing curve, and neither the announcement nor the handoff documentation says a word about it. prefers-reduced-motion is a CSS media feature "used to detect if a user has enabled a setting on their device to minimize the amount of non-essential motion". Nobody sets it on your site. They set it once, in macOS, Windows, iOS or Android, and every page they visit is supposed to respect it.

Half the web already listens. The Web Almanac 2025, which analyses the HTTP Archive crawl of 17 million sites, found prefers-reduced-motion on 49.99% of desktop pages and 50.55% of mobile ones, the most used preference query on the web, with adoption showing "little change" from 2024. That number measures one thing: the query exists in the page's CSS. It says nothing about whether anyone decided what goes inside it, and our read is that the gap is where the design decision has been missing. The branch is already in the code, waiting for a value nobody was ever asked to supply.

The reason to supply that value is not compliance. WCAG 2.2 success criterion 2.3.3 asks that "motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed", and it sits at Level AAA, the highest of the three conformance levels. Our read is that this is the point: reduced motion will not arrive through an audit, so it arrives as a design decision or it does not arrive. What arrives either way is the effect the W3C describes on the same page. For people with vestibular disorders, meaning inner ear conditions that affect balance, animation can trigger "nausea, migraine headaches, and potentially needing bed rest to recover".

What to ask for in the next review

Our position, and it is a position rather than a finding: the mechanism Figma shipped for brand consistency is the same mechanism reduced motion has always needed. A motion variable with two modes, full and reduced, puts the decision in the file where the designer makes it, instead of in an @media block a developer writes at the end of a sprint with nothing to compare against. Nothing in the launch suggests Figma will generate that branch, so it is a convention a team adopts, not a setting it enables.

A two-mode variable also makes the review question answerable. Until June, asking what a screen looks like for someone who wants less movement got you an opinion, because there was nothing to point at. Now it gets you a mode in the file, or an admission that nobody made the call.

What to watch over the next six months is narrower than adoption, because designers will adopt the timeline. It is whether the exported code carries the branch. Today Figma exports the animation you designed. If in a year it exports that animation plus the media query that turns it off, motion becomes the first design property that ships with its own accessibility default. If not, it stays something each team decides on purpose or skips by accident.

Sources