Motion Design Tokens

Motion design tokens define animation properties like duration, easing curves, and delay values in a systematic way that enables consistent motion across components and platforms. Like color and spacing tokens, motion tokens abstract animation values into named references that components use, ensuring coherent motion design throughout a design system.

What Are Motion Design Tokens

Motion tokens store values that control how animations behave. Duration tokens define how long animations take. Easing tokens define acceleration curves. Delay tokens control animation start timing. Components reference these tokens rather than hard-coding animation values.

Token-based motion design ensures consistency. A “standard” duration used across components creates cohesive motion feel. Changes to the token value update all components using it, enabling system-wide motion tuning.

Cross-platform challenges arise because animation systems differ. CSS uses cubic-bezier notation for easing. iOS uses CAMediaTimingFunction or spring parameters. Android uses TimeInterpolator implementations. Motion tokens must transform appropriately for each platform.

How Motion Design Tokens Work

Duration tokens define time values in milliseconds or seconds. Semantic names indicate purpose: duration-instant (immediate feedback), duration-quick (snappy transitions), duration-moderate (standard transitions), duration-slow (elaborate entrances).

Motion Token Examples:

Duration Tokens:
{
  "motion": {
    "duration": {
      "instant": { "value": 0 },
      "quick": { "value": 100 },
      "moderate": { "value": 200 },
      "slow": { "value": 400 },
      "elaborate": { "value": 600 }
    }
  }
}

Easing Tokens:
{
  "motion": {
    "easing": {
      "standard": {
        "value": "cubic-bezier(0.4, 0, 0.2, 1)"
      },
      "entrance": {
        "value": "cubic-bezier(0, 0, 0.2, 1)"
      },
      "exit": {
        "value": "cubic-bezier(0.4, 0, 1, 1)"
      }
    }
  }
}

Platform-Specific Output:

CSS:
--motion-duration-moderate: 200ms;
--motion-easing-standard: cubic-bezier(0.4, 0, 0.2, 1);

iOS (Swift):
static let durationModerate = 0.2
static let easingStandard = CAMediaTimingFunction(
    controlPoints: 0.4, 0, 0.2, 1
)

Android:
<integer name="motion_duration_moderate">200</integer>
val easingStandard = PathInterpolator(0.4f, 0f, 0.2f, 1f)

Easing tokens define timing curves. Cubic-bezier values work across platforms with transformation. Spring animation tokens present more challenge because spring parameters differ between platforms.

Token transformation generates platform-specific output. Style Dictionary or similar tools convert source tokens to platform formats. Duration in milliseconds might become seconds for iOS. Easing curves transform to platform-appropriate syntax.

Key Considerations

• Duration values may need platform adjustment for perceived equivalence
• Easing curve formats differ significantly by platform
• Spring animation parameters do not translate directly
• Reduced motion preferences should use appropriate token values
• Token names should indicate semantic purpose
• Testing validates that token values produce good motion

Common Questions

How do design systems handle spring animation tokens?

Spring animations use physics parameters (mass, stiffness, damping) rather than time-based curves. These parameters do not translate directly between platforms.

Intent-based spring tokens work better than parameter-specific tokens. A “spring-bouncy” token might have platform-specific implementations achieving similar perceptual result.

Platform-specific spring values within tokens provide precise control. A spring token might include ios_spring_response, ios_spring_damping, android_spring_stiffness, android_spring_damping with appropriate values for each.

Comparative testing tunes platform values. Animate similar content on each platform, adjusting parameters until motion feels equivalent across platforms.

How should motion tokens support reduced motion preferences?

Alternative reduced motion tokens provide accessible values. When reduced motion is preferred, duration-moderate might be 0 instead of 200ms, eliminating the animation.

Component implementation checks preferences and applies appropriate tokens. Token infrastructure might support automatic selection based on system preferences.

Not all motion requires elimination. Reduced motion means less motion, not necessarily zero motion. Essential animations might reduce rather than eliminate.

Design system documentation should specify reduced motion handling for each component and token usage context.

How do teams test motion token effectiveness?

Perceptual testing evaluates whether duration and easing feel right. Animations might be technically correct but feel wrong at certain speeds or with certain easing.

Cross-platform comparison ensures tokens produce similar feel. Side-by-side comparison reveals whether the same semantic token creates comparable experiences.

User testing validates motion serves its purpose. Does animation timing help user understanding? Does easing feel natural? User feedback informs token value refinement.

Performance testing confirms animations meet frame rate targets with specified token values. Longer durations allow more time for frame completion but may feel sluggish.

Summary

Motion design tokens define duration, easing, and other animation properties systematically for consistent motion across components and platforms. Token transformation generates platform-appropriate output formats. Spring animations and reduced motion preferences require special consideration. Testing validates that token values produce effective, equivalent motion experiences across all target platforms.