Animation/Motion Design Tokens for Complex Design Systems

Fundamentally speaking (with no regard for the platform), an animation lets an element gradually change from one state to another. Each animation needs at least these five parts:

1. Element — What you are animating
2. Trigger — What input causes the animation to happen (gestures, time, etc.)
3. Duration — How long should the transition take
4. Property — The characteristic of the element being transitioned (position, opacity, scale, etc.)
5. Easing — How the property or properties transition

Note: In CSS, Transitions and Animations are slightly different. Transitions are limited to an initial and final state, but Animations can include many intermediate states (keyframes) between the initial and final state.

Design Systems and Animation

In an attempt to standardize some of those 4 parts in Animation Design (mainly easing and duration), most Design Systems use Motion Design Tokens.

$easing-data: (
   base: cubic-bezier(0.64, 0, 0.35, 1),
   in: cubic-bezier(0.36, 0, 1, 1),
   out: cubic-bezier(0, 0, 0.42, 1),
   …
   …
) !default;

$og-duration-data: (
   fast: 50ms,
   base: 85ms,
   slow: 150ms,
   …
   …
) !default;

However, giving these to designers and developers presents some challenges. To start, they are not technically Design Tokens; they are variables. Ideally, Tokens should communicate intent within a context/interaction and let designers and developers know when and how to use a particular design decision by just reading the name (a.k.a token).

In big organizations, with hundreds of designers and thousands of developers, making these variables available by themselves may create inconsistencies as every designer chooses slightly different variables for similar transitions.

Problem

Two designers working at different product areas may end up speccing the same transition (expanding or collapsing a container, for example) with vastly different animation specs. Thus, the user may encounter inconsistencies as they move between UI areas designed by different designers.

Solution

Create new tokens that convey intent.

Every animation on digital screens, no matter how complex, uses one or more of the following transitions — there could be more, but these are the ones I see most.

🎚 Slide In and Slide Out

👻 Appearing and Hiding

🕴 Hovering in and Hovering Out

💗 Expanding and Shrinking

🔍 Zooming in and Zooming out

Encapsulating at least the Easing and Duration into a token that conveys intent allows designers to worry only about choreography in animations. It also makes sure that these transitions are scalable and consistent across different usages.

Below is a basic example of how these are combined. When designing transitions that convey Deleting and Adding actions, a designer may want to affect opacity (Appearing and Hiding) and Expand or Shrink an object.

Looking at a more complex and exaggerated example, by using these Tokens, the designer would simply have to indicate what triggers the animation, what elements animate, what Tokens to assign to each element, and when will each element start animating— In other words, the choreography of the animation.

Note: Like with any Design System, there might be cases in which these tokens may not work for a specific use case, and the designer may have to create a specialized combination of duration and timing. However, in system design at scale for large apps, this is very rare and in most cases avoided.

Stay safe,

Oscar.

If you have any feedback/comments/suggestions, please share them in the comments. I would love to hear your thoughts.