How to transfer animations to the developer so that he does not simplify them to static

The animation in Figma looks like magic: easing is soft, elements breathe, transitions hold attention. You open production in two weeks and you see a 200 ms fade-in on everything that moves. The button just pops up. The card just rolls. No magic.

Normally, this is not a sabotage of the developer. This is a natural result of how the animation is conveyed: the words “well, it should be nice to go out here,” a reference to a prototype that no one opened, and a comment in Jira “add smoothness.” In such a brief, any normal frontender will do the minimum - because the maximum is not described, evaluated and not protected.

This article is about how to describe the movement so that it reaches the user in the form in which it is intended. No “let’s watch it together” every time.

## Why animations are consistently lost on handoff

Animation is the most poorly documented layer of design. Fonts are in tokens, colors are in the library, indentations are in auto layout. And motion exists as a video in Loom, a prototype in Figma, and a verbal arrangement. Any of these links break first.

A few common reasons why animation becomes static:

• No numerical parameters. "Smooth," "soft," "like Apple" is not a specification. The developer will default the framework.
• **No priority. ** In the box, animation is the last item. When the deadline hits, they cut it off.
• ** Not clear target. ** If it is not clear why the element moves, the movement is perceived as an ornament. Jewelry is cut first.
• There is no way to verify. QA doesn't know how to test the "correctness" of an animation. If you can’t do it, you can’t do it.
• Performance is intimidating. Developer is not sure if 60fps is realistically achievable, and simplifies it proactively.

If you want the movement to survive, you have to shut down all five reasons, not just the first.

## First, decide why there is any movement

Before describing curves and timings, answer one question: What does this animation do for the user? If there is no answer, the animation is really worth throwing away, and the developer is right.

The work functions of the movement, under which it is necessary to protect the budget:

• Preserve context. The element does not disappear or appear out of nowhere – the user sees where it came from (opening the card in its place, leaving the panel from the side).
• **The Hierarchy of Attention. ** One thing moves slower or later, you look at it.
• Feedback. Pressing, downloading, success, error - without movement they read worse.
• Skeletons, progress, transitions between modes – movement shows what the system does.

If animation does not fall into any category, it is decoration. They'll cut it off for a rev, and that's okay.

### Questions that every piece of movement must answer

• What does the user need to understand through this movement?
• What will break if you remove the animation altogether?
• What will break if you leave only 150 ms fade?
• Is it blocking animation or background animation?

The last question is particularly important. Blocking (modular opens, button responds to tap) - critical, it can not be cut. Background (parallax, easy breathing of the icon) is pleasant, it can be turned off on weak devices. These two categories need to be clearly differentiated, otherwise the developer will average both.

## Describe the movement so it can be coded without you

The minimum specification of a single transition is not “open the prototype and see.” This is a set of parameters that can be read, entered into the code and checked.

### What should be in the description of each animation

• Trigger. What triggers it: Mount, click, hover, state change, scroll, appearance in viewport.
• **Property: opacity, transform (translate/scale/rotate), color, size. Not "card appears," but "opacity 0 → 1 and translateY 12px → 0.".
• Duration. ** In milliseconds. Not "fast.".
• Easing. Specific curve: cubic-bezier(0.2, 0, 0, 1) or name from your token system (ease-out-standard). Ease by default is not easing, it is a lottery.
• ** Delay.** If there is. This is especially important when orchestrating several elements.
• End state. What should remain on screen after completion.
• ** Interrupt.** What happens if the user clicks again during the animation. Reverse? Ignor? Relaunch from current position?

The last point is the most underrated. Half of the “big” animations in production are not bad easing, but an unworked interruption.

## Transfer workflow: from layout to specification

Most studios broadcast animation in one of two ways: “Here’s a prototype in Figma, look,” or “Here’s a video from After Effects, repeat.” Both methods break down for one reason: the developer has nowhere to get numbers. The Figma prototype does not show easing in the Bezier curve format, and the video does not distinguish between 280 ms and 320 ms per eye. As a result, he sculpts something close and gives it to the review.

A workflow that doesn't fall apart on the second sprint looks something like this.

### Steps worth recording in the team

1. Mark animations in the layout. Right on the frame - dot, badge, layer MOTION. Any way you look at the screen is to say, “There’s movement, you can’t miss it.”.
2. Prepare a motion-spec next to the UI-shop. Not a separate document in Notion that no one will open. This is either a page in a Figma file next to the screen or a comment in a Storybook/code. The main thing is close.
3. **Duration and easing should live in a design system like colors. duration-fast, duration-base, ease-out-standard. When a developer writes code, it substitutes a token, not a magic number.
4. Give video reference - but only in addition. Video is useful as "this is how it should feel," but numbers are always more important. If the video and the spectacle contradict, the spectacle wins.
5. Conduct a motion review before release. Separate meeting for 20 minutes, where the designer and developer clinch animations together. Not on the demo with the whole team - you can't see them there.

### What to put in motion tokens and what not

In tokens there are parameters that are repeated. Level durations (75/150/250/400 ms), standard easing (ease-out-standard, ease-in-out-standard, ease-spring-soft), orchestration delays (stagger 40 ms).

Unique animations do not go into tokens - a corporate logo, landing an illustration on onboarding, celebrating success. They are described as a one-off speck with numbers and video. Don’t try to tokenize everything, you’ll get a system that nobody uses.

## How to Diagnose That Movement Has Been “Simplified”

Often the designer sees that “something is wrong” but can’t articulate what it is. It is useful to have a checklist for quick diagnosis.

### Symptoms and what they usually mean

• Everything moves the same way. Most likely, the developer substituted one transition for all elements. No hierarchy.
• Animation works on the mountain, but not on unmounting. Standard React/Vue story: coming cheap, disappearing requires a library. If it is not laid, the elements simply disappear.
• It's all twitching. ** The property is animated in the wrong way - for example, width instead of transform: scale. The browser recalculates layout, frames are lost.
• Animation speeds up with a quick click. Interrupt is not processed: each click launches a new twin on top of the old one.
• **On a weak phone everything is laid. ** Animated heavy property or too many at the same time. Background movements are not off.
• ** On demo, it's okay, on sale, static. ** There was no animation library or prefers-reduced-motion, which no one consciously configured.

### Questions for a review with a developer

• Which properties are actually animated – transform/opacity or layout properties?
• What happens when you re-trigger during animation?
• What happens with prefers-reduced-motion: reduce? Full shutdown or shortened version?
• What happens if the animation starts while scrolling or opening the keyboard?
• Tested on the weakest device in the support matrix?

If the answer to half of the questions is “didn’t think”, you don’t have an animation, but its draft.

## Typical Designer Mistakes That Cut Movement

The developer is not always to blame. Often animation is simplified because the designer himself made it unnecessary.

• I gave the prototype without numbers. I can see it there. 200 ms and 400 ms per preview are almost indistinguishable, and in the product these are different sensations.
• Done animation for portfolio. 12 items are delayed, total entry is 1.4 seconds. The demo is beautiful, in real use annoying after the third time. The developer feels it and cuts it.
• I didn’t think about empty and erroneous states. **Speak is only for the happy path. What happens when an error occurs, when the network is slow, when the list is empty, is not described. The developer does it himself, usually badly.
• Ignored accessibility. If the animation does not have reduce mode, it will either be left as it is (and broken by people with vestibular disorders) or turned off completely.
• **Made the movement the only signal. ** If the error is shown only by swaying the field, without color or text, it is not available. It's a fair rehearsal.

## How to apply this directly in the layout

You don’t have to build a big system right away. You can start with one screen.

• Take the nearest float that goes into development. List all transitions and microinteractions with a list of how many there are.
• For each item, set: trigger, property, duration, easing, interruption. If you do not know, this is the hole through which the movement flows.
• Note what is blocking and what is background. Sign the background as “you can cut to low-end”.
• Collect 2-3 short videos – not one big video, but individual clips of 3-5 seconds for each key transition. The developer will really look at it.
• At motion review, go through the list and check the boxes. What is not implemented – get tickets with priority, not items in Notion.

### Segment summary

Animation survives not where it was beautifully shown, but where it is impossible to accidentally lose it: numbers in tokens, the sinter next to the screen, the interrupt is described, the background is separated from the blocking, the review is conducted separately. Everything else is a matter of taste, which will lose the deadline.

## Advanced Scenarios: Where Traffic Breaks Most Often

Simple hovers and appearances almost always outlast development. It is more difficult with conditions that are rarely found in the layout, but constantly in the product.

### Animations inside lists and virtualized collections

Lists with more elements are often rendered through virtualization – cards appear and disappear from the DOM as you scroll. If you have laid down the card input animation, it will play every time you return to that item. On the third proscroll, this is no longer a “live interface”, but a nervous tic.

What to fix in the speck:

• Entry animation is played once per session or only at the first mountain.
• When reordering (drag, filter, sorting), a separate transition is used - usually through FLIP technique, rather than repeated mount animation.
• Skroll during animation it is not interrupted by a jerk, and extinguishes smoothly.

### Transitions between screens and shared element

If in the layout the card is “turned” into a detailed screen, the developer will almost certainly implement it as two independent screens with a fade in between. Shared element requires either native support (View Transitions API, Navigation on mobile) or manual position synchronization.

Here it is important to answer in advance: what happens if the user presses back in the middle of the transition? What if the screen data hasn’t arrived yet? Without these answers, the shared element will be thrown out and replaced with a cross-fade.

### Animations tied to data

Counters, progress bars, graphs that “reach” the value. A common mistake is to describe them as “smoothly changing to X.” In life, the value can come twice in a second, come with a delay or go back to the old one when you make a mistake. Describe three cases: first appearance, update in flight, recoil if you make an error. Otherwise, the developer will put an instant assignment and be right.

## AI and Figma MCP: where it helps and where it hinders

Now it often sounds “let’s give the layout to AI, he will collect animations himself”. In practice, this works only under one condition: there are already specks and tokens. Then the AI assistant in the IDE can correctly substitute durations, easing and bind prefers-reduced-motion. Without tokens, it will invent values and they will be different in each file.

Where AI really speeds things up:

• Generate hover/focus state code according to the description "scale 1.02, 120 ms, ease-out, transform-only".
• Rewrite animation from layout properties to transform.
• Add interrupt processing to an existing component.
• Make a reduction-motion option on the main.

Where he's consistently wrong:

• Complex orchestration between components.
• Scenarios where you need to understand the product context: which animations are blocking, which background.
• Performance on a particular device – the model does not know your support matrix.

Figma MCP and similar layout-to-code bridges are useful for statics and basic interactions. The animation they transmit poorly: in the layout it is simply not in full form. Therefore, video reference and numerical speck remain mandatory, even if the rest of the markup is collected by the agent.

Separate risk: AI willingly “improves” animations, making them more expressive than you thought. On the review, this is caught by the same checklist as the work of a person - what properties, what durations, what with interruption.

## How to check the quality of movement, not just the presence

“Implemented” and “implemented correctly” are different things. In order not to argue on taste, make measurable checks.

• Remove the screen with animations at 60 and 120 fps slow-motion phone. Do you see frame slips, jerks at the start, trembling at the end.
• Open DevTools Performance, start the animation. Look at the long drags in the main thread and what properties trigger layout/paint. The ideal is composite-only.
• Check on the weakest device in the support matrix, not your laptop. If the team doesn’t have one, it’s a separate problem, not about animation.
• Turn on prefers-reduced-motion in the system and go through the same flow. A shortened version should work, not a broken interface with missing transitions.
• Start the animation, interrupt it in the middle with a new trigger. Behavior should be described in terms and coincide with implementation.

### Checklist motion review

• All blocking transitions are within the declared duration.
• Background animations can be turned off with a flag or they are turned off at low-end.
• Only transform and opacity are animated, except as expressly agreed.
• Interruption is described and works: the new trigger does not fuse with the previous one.
• Reduce-motion makes sense, not empty screens.
• Animation is not the only signal of state - there is text, color, icon.
• On the weakest device from the matrix there are no frame drops at key transitions.

## How to explain the decision to the team

The most common reason motion is simplified is that no one but the designer understands why it is. The developer sees the work, the product sees the deadline, QA sees the bug "incomprehensible flicker." If you have not explained the role of animation, it will be cut as decoration.

What works in meetings:

• Show two screen options in a row: without animation and with it. Not for beauty, but to record what information the movement carries — hierarchy, causation, feedback to action.
• Attach each animation to a product task: “This transition shows that the data has been updated, without it, the user presses the button a second time.” This is the argument that will remain after you in the ticket.
• Divide the movement into “compulsory for meaning” and “pleasant but optional.” The first protect, the second calmly give for reduction. If you protect everything the same, don’t protect anything.
• In retro after the release, go back to the animations: what survived, what simplified, what broke in the sale. This turns the movement from a taster's taster into a normal engineering object that has a history and metrics.

### Segment summary

Complex scenarios — lists, transitions between screens, data — are lost more often than simple ones, because they rarely write full speculation. AI and MCP help only on top of a ready-made system of tokens and rules, otherwise they multiply in variety. Quality is tested on a weak device, in DevTools and with reduced-motion enabled, not on the designer’s laptop. And most importantly, animation survives where the team understands its role in the product, not where it was beautifully defended once on a pitch.

The final segment is about how not to step on typical rakes and what to ask yourself and the team before considering the transfer of animations completed. The checklists below work as a filter: if at least one item “don’t know”, the transfer is not ready yet, no matter how beautiful the Figma file looks.

## Anti-patterns that make movement static

This is not about the evil will of the developer. This is about holes in the production, which any team will fall into by default.

### The animation is in the layout, the rest is clear

The biggest mistake ever. In the layout is a prototype of 200 ms, no curve, no description of interruption, no behavior on a slow network. The developer honestly does "like in Figma" and gets a flat fade because there was nothing else there.

### One steak for the whole app

"Using ease-out 250ms for everything" sounds like a system that works like an equalization. Small toasts at such parameters are felt sluggish, large curtains are ragged. Speck should distinguish between classes of movement: micro-feedback, transitions inside the screen, changing screens, background processes.

### Video reference without numerical speck

Recording from Principle or After Effects convinces on the pitch, but does not convey durations and curves. The developer shoots by eye, and any discrepancy is written off as “well, about that.” After a month, you won’t be able to prove that it was designed differently.

### Animation as the only state signal

The "sent" button only flashes and disappears. On the reduce-motion and slow device, there is no signal at all. Any movement that makes sense must be duplicated by text, color, or icon.

### "Finish the polish."

Animations postponed to the polishing stage do not reach the release almost never. By this point, there is a scope of new features, bugs and a deadline. If movement is important, it is part of the main task, not an appendix to it.

### Protection of all animations as mandatory

If at the review you argue equally fiercely for the transition modal and parallax on the landing, you stop listening. The team learns to cut everything because they don’t see the line between ‘need’ and ‘nice’.

## Final checklist of the transfer

• For each animation, there are: trigger, properties, duration, curve, delay.
• Behavior at interruption and at repeated trigger is described.
• There's a version for prefers-reduced-motion, and it makes sense.
• Specifies on which devices animation is required, and where it can degrade.
• Animations are tied to movement tokens, not magic numbers in the code.
• Video reference is applied in real speed, without slowing down for beauty.
• Complex scenarios (lists, transitions between screens, data loading) are painted separately, not by analogy.
• For each animation, it is clear what product problem it solves.
• A method of checking is agreed: what exactly does QA reveal to say "done.".

## Questions for the audit

These questions should be asked both on the design review of the specks, and on the code review of the implementation. They quickly uncover weaknesses.

• What happens if the user presses the trigger a second time during the animation?
• What will a person with reduced-motion enabled see on this screen?
• What properties are animated and why exactly are they?
• How does this animation behave on the weakest device in the support matrix?
• If you remove all traffic, what information will be lost?
• Where is the duration described – in the code, in tokens, in the layout? Are the values the same?
• Is this animation necessary for meaning or is it a nice decoration? And are we protecting it appropriately?
• What do we measure after release to see if the movement is working?

## Short practical outcome

Animations aren’t made static because developers can’t make them. They are cut when the movement has no clear role, no numerical speck, no space in the token system, and no way to verify the outcome. All this is solved not by persuasion in retro, but by engineering accuracy on the design side: timings, curves, interruptions, behavior on reduce-motion and on weak devices are prescribed before the ticket gets into development.

Then there is a simple rule: protect the mandatory, calmly give the optional, and every time after the release, return to see what survived in the sale. After a few iterations, the movement in your product will cease to be a taster and become as normal a part of the system as grid and typography – with its own rules, its own metrics and its own decision history.