LanguageEnglish
Pillar 06 · Design Systems
Motion Tokens: The Complete Architecture for Design Systems
Standardize motion across your entire product ecosystem. Stop hardcoding arbitrary 300ms cubic beziers across dozens of developer repositories.
What is Motion Tokens: in ExodeUI?
Motion Tokens are standardized design tokens that define animation parameters—such as spring stiffness, damping ratio, mass, easing curves, and duration—in a machine-readable format. Our free Motion Token Generator creates a starter set you can export for CSS and JSON, and token build tools turn them into code for each platform.
Core Architecture
Why Engineers & Designers Choose ExodeUI
Design, logic and motion in one file that runs inside your app.
Spring Physics Tokens
Define motion with physical tokens (stiffness, damping, mass) rather than arbitrary timing numbers.
Automated Code Generation
Turn tokens into CSS variables and platform code with your existing token build pipeline.
Semantic Hierarchy
Organize motion tokens into global, semantic, and component levels (e.g. motion.spring.snappy, motion.feedback.success).
Design Tool Synchronization
Sync motion tokens seamlessly between Figma variables and production Git codebases.
Objective Evaluation
How ExodeUI Compares to Traditional Design Tokens (Color/Type Only)
Where ExodeUI is stronger, and what to weigh before you switch.
ExodeUI
- Full first-class support for physical spring tokens and velocity curves
- Exports to native mobile (SwiftUI/Compose) and web formats simultaneously
- Visual inspector lets designers feel token physics in real time
- Automatic accessibility fallbacks for prefers-reduced-motion
Traditional Design Tokens (Color/Type Only)
- Most token tools only support static colors, typography, and spacing
- Motion is reduced to crude duration strings like "300ms ease-in-out"
- No visual way to test token dynamics before shipping to code
- Engineers must manually interpret motion specs into framework code
Developer Handoff
Using It in Your Code
Your app loads the compiled file through the ExodeUI runtime and talks to it through inputs and events.
import { ExodeUICanvas } from 'exodeui';
// Springs, states and timing live in the .exode file (designed in the
// editor). Your code passes inputs in and hears events back.
export function SnappyButton() {
return (
<ExodeUICanvas
src="/snappy_button.bexode"
onTrigger={(name) => console.log('ExodeUI event:', name)}
/>
);
}Why Design Systems Fail at Motion
Modern design systems have perfected color palettes, typography scales, elevation shadows, and spacing grids. But motion remains the forgotten design token. In most organizations, motion documentation consists of vague guidelines like "animations should be snappy" or a static 250ms duration variable.
- Inconsistent Brand Feel: One engineer uses ease-out, another uses ease-in-out, and mobile uses Apple defaults.
- Brittle Duration Curves: Timed animations feel slow on small elements and hurried on large bottom sheets.
- Accessibility Neglect: Teams fail to implement cohesive reduced-motion overrides across all components.
The 3-Tier Motion Token Hierarchy
ExodeUI models motion tokens across three structured tiers:
Tier 1: Global Primitive Tokens
Raw mathematical constants (e.g., stiffness-400, damping-25, mass-1).
Tier 2: Semantic Intent Tokens
Functional names tied to intent (e.g., motion.interactive.snappy, motion.modal.enter).
Tier 3: Component-Specific Tokens
Overrides bound to specific components (e.g., button.toggle.switch).
Topic Cluster Network
Explore Connected Concepts & Tooling
Got Questions?
Frequently Asked Questions
Build living components with real motion.
Start free in the browser or download the desktop app. Compile spring physics and state machines directly to React and SwiftUI.