Motion Tokens: The One Thing Missing from Your Design System

So, I've been meaning to write this up for a while because I genuinely think this is one of those things that sounds boring until it clicks, and then you can't stop thinking about it.

A bit of background: I'm Jaime, a Motion Design Strategist at LottieFiles. My job is basically to work with brands and help them figure out how to build motion into their workflows properly. And I keep seeing the same problem everywhere I go.

Teams have spent years getting their design systems right. Colors tokenized. Typography tokenized. Spacing dialled in. But then I ask about motion and it's a completely different story. Scattered files, developers hardcoding hex values into JSON they don't fully understand, and the moment someone updates a brand color… chaos. I've seen this at companies with five people and companies with five hundred.

What are Motion Tokens?

I'll skip the marketing speak: Motion Tokens are named variables that map to specific properties inside your Lottie animation. Color, text, transforms; instead of those values being baked into the file forever, you expose them as inputs that can be changed at runtime from your code.

Think of it as giving your animation an API. You design the animation once, and your devs just pass in the right values. The animation does the rest.

dotLottie.setTokens({
  "brand_color": "#00FF00",
  "user_name": "Welcome, Enterprise User!"
});

That's it. One file. Multiple brands. I actually let out an audible "oh" when I first saw this work.

The real problem it solves

One pattern I see constantly: a team has a "success" animation, such as a satisfying little checkmark thing and they need it to work across five sub-brands with five different primary colors.

Without motion tokens, that's five separate Lottie files living in five separate corners of a DAM system, being maintained (or more accurately, not maintained) by five different people. One brand updates their green. Three months later someone notices the animation is still using the old green. I've watched this exact scenario play out more times than I can count. These are the kinds of things that quietly erode trust in a design system.

But with motion tokens, not that’s a gamechanger; it’s one master file. Pass in the brand color token at runtime, done. Brand consistency goes from "vibes-based" to actually enforced.

The handoff problem (this is the bigger win)

The multi-brand thing is cool but honestly the thing I hear about most when I talk to teams is the design-to-developer handoff.

The old way: handing off a motion asset meant writing a three-paragraph Notion doc explaining where in the JSON the hex value was buried, attaching a Loom video of the easing curve, and then watching a developer implement something that was close but somehow not quite right. Every. Single. Time.

With motion tokens, designers define them in Lottie Creator and developers see a clean, documented list of inputs. There's a shared vocabulary. Teams I've worked with have cut their motion handoff back-and-forth significantly just by switching to this workflow.

Who actually needs Motion Tokens?

If you're a solo designer making animations for one product, this might be overkill. It's not hard to set up, but there is a learning curve.

Check out this video from George, our Senior Product Manager, if you’re more of a visual learner.

But if you're working in a larger org, such as multiple brands, multiple platforms, multiple developers touching animation files, this is genuinely the missing piece of your design system. I talk to teams every week who have tokenized everything except motion. That gap always shows eventually.

The real-time data use case (bonus)

This is one of my favorite things to demo. Imagine a weather widget where the background gradient shifts based on actual temperature, the city name updates dynamically, and it's all one Lottie file responding to live data. The possibilities here are genuinely exciting and most teams haven't even thought about it yet.

Some use cases I keep coming back to:

• Weather and environment: Background gradients shift with live temperature, wind animations speed up or slow down, sky color changes based on time of day. One file, infinite conditions
• Fintech dashboards: Portfolio performance animations that react to real numbers, green/red color states driven by market data, animated counters that pull live figures at runtime
• E-commerce: Product launch countdowns, stock level indicators ("only 3 left" triggers a different animation state), personalised welcome animations that greet users by name
• Ride-sharing and logistics: Live map animations where vehicle position, ETA, and route color update in real time from a single Lottie asset
• Health and fitness apps: Progress rings and goal animations that fill based on actual user data, color shifting from red to green as targets are hit
• SaaS dashboards: Animated KPI widgets tied to live metrics, onboarding checklists that animate as steps are completed, status indicators that change state based on system health
• Sports and live events: scoreboards, timers, and celebration animations that trigger from live event data without needing separate files per team or outcome
• Localization and personalization: Same animation file, different language text injected at runtime, different brand colors per market, all from one source file

TL;DR

Motion has always been the last frontier of design systems. Teams solve color, type, spacing — and then leave motion as an afterthought. Motion tokens finally bring Lottie animations into the same system as everything else. That's what we built this for.

Key takeaways of Motion Tokens:

• One animation file, infinite brand variations at runtime
• Cleaner design-to-dev handoff with a documented token API
• Reduce DAM bloat by eliminating redundant animation files
• Dynamic, data-driven motion for real-time products
• Motion finally lives inside your design system, not outside it

If your design system has a motion problem, this is where I'd start looking. Happy to answer questions; this is literally what I spend my days thinking about.