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: — What you are animating Element — What input causes the animation to happen (gestures, time, etc.) Trigger — How long should the transition take Duration — The characteristic of the element being transitioned (position, opacity, scale, etc.) Property — H the property or properties transition Easing ow : 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. Note 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. … … ) !default; … … ) !default; $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 ), $og-duration-data : ( fast: 50ms , base: 85ms , slow: 150ms , However, giving these to designers and developers presents some challenges. To start, t ; they are variables. Ideally, Tokens should communicate within a context/interaction and let designers and developers know and to use a particular design decision by just reading the name (a.k.a token). hey are not technically Design Tokens intent when how 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 and 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. Easing Duration 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 ( ) and Expand or Shrink an object. Appearing and Hiding 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. : 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. Note Stay safe, . Oscar If you have any feedback/comments/suggestions, please share them in the comments. I would love to hear your thoughts.