UI design tools have come a long way. With the rise of design systems, component libraries, and real-time collaboration, creating consistent, scalable interfaces is faster and more systematic than ever before. Tools like Figma have given teams a shared source of truth for visual design — but motion hasn’t caught up.
Despite being a core part of how users perceive and interact with digital products, animation remains fragmented, fragile, and disconnected from the design system itself. We rely on one-off prototypes, throwaway timelines, and handoff methods that feel outdated in 2025.
So where is the “Figma for motion”? Why hasn’t UI animation earned a first-class seat in our toolkits? And what would a truly reusable, systemized animation workflow look like?
The Current Landscape: Workarounds, Not Solutions
When designers need to communicate motion, they turn to a mishmash of tools: After Effects, Principle, ProtoPie, Framer, Lottie, Smart Animate in Figma — the list goes on. Each has strengths, but none have cracked the fundamental problems:
- Lack of Reusability: Animations are often built from scratch, even when similar patterns already exist elsewhere.
- Poor Integration with Design Systems: Motion doesn’t live alongside components, tokens, or themes — it lives in separate files or videos.
- Fragile Handoff: Developers are usually handed a GIF, MP4, or vague timing notes, not something inspectable or spec-ready.
- Throwaway Workflows: Most motion work can’t be versioned, reused, or treated as a system artifact.
Even in tools that support motion, animation is too often an effect, not a first-class object.
What Design Systems Actually Need from Animation
As design systems mature, so do the expectations for consistency and scalability — and that includes motion. Motion isn’t just eye candy. It communicates relationships, hierarchy, continuity, and responsiveness. That means we need ways to treat it with the same rigor we apply to type, color, and spacing.
Here’s what a design system truly needs from motion tooling:
- Motion Tokens Duration, delay, easing, and curves should be tokenized — abstracted, named, and theme-able just like colors or spacing.
- Animation Patterns Common behaviors like entrance/exit, transitions, state changes, and microinteractions should be reusable and named. Think of them as “motion components.”
- Consistency Across Platforms The same motion pattern should scale to web, iOS, and Android — not be reinvented each time.
- Version Control & Source of Truth Motion definitions should live inside the system — documented, inspectable, and change-tracked.
Today, none of our tools offer this in a centralized, scalable way.
Why Reusability Is Still Missing
We wouldn’t accept a design system where every button had to be redrawn from scratch. Yet that’s exactly how most teams treat motion.
If a designer wants to use a common transition — say, a modal fade or a slide-in drawer — they often have to rebuild it manually, tweak timing by hand, and record a new prototype. That animation can’t be saved as a preset. It can’t be applied across components. It can’t be versioned or themed.
Even Smart Animate, Figma’s most used animation feature, relies on layer matching and artboard hacks — not true motion logic. There’s no way to define and reuse a specific animation across multiple components with shared logic or tokens.
The result? Animation becomes bespoke, brittle, and inconsistent — exactly what design systems are meant to prevent.
And here’s the ironic part: sometimes it’s actually easier to build reusable motion in code than in a design tool.
Modern frameworks like React, Flutter, or SwiftUI let developers define motion as abstractions: reusable fadeIn(duration, easing) functions, springTransition() utilities, or even platform-level motion tokens. These can be shared across components, themed globally, and synced across apps. Want to update a duration? Change one constant.
Designers don’t have that luxury. Most design tools still treat motion as something fixed to a timeline or linked to layer position, rather than as something symbolic, abstracted, and semantic. There’s no way to define a duration.sm or ease.outExpo token and apply it universally. Which means that — in many cases — the only place motion is truly reusable is in code.
After Effects Got Close — But Only If You Knew Expressions
Ironically, one of the few tools that allowed atomic, programmable motion wasn’t made for UI at all: it was After Effects.
For designers willing to go beyond keyframes and timelines, expressions offered a kind of motion logic that feels closer to modern code-based animation. With a few lines of scripting, you could create behavior-driven, consistent motion that responded to other layers or system-wide rules.
Here’s a classic example for staggered animation:
delay = 0.1; myIndex = index - 1; thisComp.layer(1).transform.opacity.valueAtTime(time - (myIndex * delay));This tiny snippet lets each layer’s opacity animate with a cascading delay — all based on its index in the layer stack. Want to tweak the spacing? Change one variable. Want to reverse the order? Change the expression once.
In short: you could build animation patterns, not just timelines.
Even more advanced expressions allowed for spring physics, bounce easing, or modular interactions — all editable, repeatable, and driven by logic. For those fluent in expressions, After Effects became a kind of motion IDE.
But of course, AE was never built with components, tokens, or developer handoff in mind. It had no concept of design systems, and integrating this logic into real UI workflows was a dead end.
Still, it proved a point: atomic, programmatic motion is not only possible — it’s better. We just haven’t built the right tool around it yet.
The Dev–Design Handoff Is Still Broken
Even when a designer nails the motion, the next step is often… a video. Or a slide. Or a verbal walkthrough. Motion remains incredibly hard to spec — and most tools don’t offer developers anything close to inspectable values.
So developers guess. Or rebuild. Or skip it entirely.
Imagine handing off a color palette by describing it in words: “a warm medium blue with a subtle gradient.” That’s where we still are with animation.
What’s needed is a bridge — not just a video, but structured, inspectable data: easing, duration, curve type, dependencies, triggers. Ideally, motion patterns would export to code (CSS, iOS, Android) or sync via tokens.
Right now, that bridge doesn’t exist.
What a True Animation Tool Should Look Like
Let’s imagine what a proper, design-system-friendly motion tool could be. Here’s what it needs to offer:
- Motion as a First-Class Object Animations aren’t just timelines — they’re part of components. Just like Variants or Properties, motion should be applied contextually and saved as part of the system.
- Motion Tokens Teams should be able to define ease-in-fast, duration-xs, or bounce-overshoot and apply those across components — and change them globally.
- Reusable Animation Patterns Just like components, animations should be abstracted and reused: “slide in”, “fade with delay”, “expand-collapse”.
- Cross-Platform Ready Exporting motion as CSS keyframes, Android motion XML, or iOS Core Animation should be table stakes.
- Interactive Preview + Spec The developer should be able to inspect an animation like they inspect a color — seeing curves, values, triggers, and code output.
- Collaboration & Versioning Motion definitions should be part of the system file — tracked, commented, iterated, and rolled back.
Until that exists, teams will keep rebuilding the same transitions, arguing about easing curves, and handing off animations as videos instead of specs.
Closing Thoughts: Motion Deserves Better
The design tools we use shape the systems we build. Right now, those tools treat motion as an afterthought — a nice-to-have flourish bolted onto otherwise static components.
But motion isn’t a decoration. It’s UX. It’s communication. And it’s overdue for a better home.
Design systems have taught us to think in tokens, patterns, and systems. Our animation tools need to catch up. We don’t need another timeline editor — we need a true design tool for UI motion. One that treats animation as reusable, inspectable, and systematic from day one.
The opportunity is still wide open.
If you’re working on a tool like this — or trying to solve these problems inside your team — I’d love to connect.
