Motion Design System — A Practical Guide
We all know the importance and value of using a well-built design system for designing digital products. However, when I accepted the challenge of creating and documenting the complete motion design system of our product, I was amazed to see that other than few examples of few specific things, there are almost none references and guides on the internet on how a motion design system should be built, delivered and maintained.
After consulting with a couple of my designer friends and colleges, I learned that many startups and even big companies don’t standardize their animations. As weird as it may sound, front-end developers often “hacking their way” with trial and error to get the animations done exactly the way the designer intended.
Using a standard motion design system may benefit your business with:
- Much shorter animation developing time
- System-wide motion consistency
- Faster decision making when designing new animations
This article will show you step by step how I created and delivered our motion design system.
This is not a guide on how to design motion graphics properly, but a manual on how to document, maintain and handoff animations to development.
The Anatomy
Just like the atomic design approach, each complex animation is built by organisms, molecules, and atoms. Developers can create “classes” for each element and re-use them when developing new animations. Classes grant consistency and make system-wide modifications very easy.
Step 1 — Defining Standard Duration Tokens
The first we’ll want to do is to create a set of duration increments and give them tokens. A token is a name we give to a certain time unit. Just like H1 is a token of a bold, size 48 headline, F2 can be a token of 200ms. Both cases serve the same purpose — maintain consistency and easier system-wide modification.
Whenever we will want to define the duration for an animation, we will use the tokens rather than giving numerical value. This is an example for a token chart:
In some cases, we will want to use “dynamic durations” that are based on the distance or the size of the object. For example — “the animation lasts 50ms for every 10% of the viewport traveled”.
Step 2 — Defining Standard Easing
The next step is to define standard values for all of our easing types. The best practice is to have an entrance easing (ease out), exit easing (ease in), standard easing (ease in — ease out) and a linear “easing”.
Step 3 — Defining Basic Animations
Now we will define basic animations. Basic animations are transitions of 1 or 2 elements, for example — opacity and position. We will use these basic animations for defining more complex ones.
Step 4 — Defining Animation Patterns
Animation patterns are a combination of a couple of basic animations. Those patterns also have their predefined easing — marked with a tag.
Couple of animation patterns we are using:
Here again, the developers can create a pattern once and give it a class, and then re-use it again and again.
Documenting Animations
For us, the easiest approach to deliver animation specs is using a diagram chart which I’ll show you how to do.
For a diagram chart, we will use our selected design tool to create a symbol (or a master component) for the chart. We will use this symbol across the entire documentation. Leave some space to the left for animation labels.
Next, we will build bars for the duration increments we have built-in step 1. Also, include a label on them stating their duration class.
You can also create a symbol for the component & animation label, just like the example below.
In more complex animations, I recommend attaching an MP4 of the animation. You don’t have to animate any sort of a popover menu, but just one that represents the animation.
Putting This All Together: Example 1
Now, we will take a typical rollover animation of a card and see how this system in action.
Let’s break down the players in this show:
Card’s BG: moves 5px up and drop shadow is changing
Card’s content: moves 5px up
Disappearing content: moves 5px up and fading out
Entering content: moves 5px up and fading in
As you may have noticed, we can use our pre-defined basic animation and animation patterns to label the choreography. Doing so will also define our easing. This is how I used my classes to define it:
Card’s BG: Elevate-Up (animation pattern)
Card’s content: Move (basic animation)
Disappearing content: SlideOut-Up-5 (animation pattern)
Entering content: SlideIn-Up-5 (animation pattern)
The only thing that we missing now is the delay and duration of each animation. For this, we will use the chart.
If you feel like your animation is a bit more complex and the component’s name isn’t enough, you can add a visual guide.
Putting This All Together: Example 2
Now we will take a tabs transition animation, and we will try documenting it via our system
What we have here:
Slider (black underline): Moves left/right
Tab’s exiting content: fades out to the left, ease in
Tabs entering content: fades in from the right, ease out
Let’s throw these components on our chart:
More Consistency — Less Charts
When we write the documentation, the aim is to cover as many use-cases with the least amount of variables. For example, I will use the same rollover “chart” for all of my buttons and links, and the same chart of all kinds of popover menus.
Handoff to Development
So now when we have all of our charts ready, you can use tools like Storybook or Confluence to store all of the information in one source of truth.
You’re all set.
I hope this guide is practical enough for you to start working on your new motion design system. If you have questions, suggestions or even intersting opportunities, don’t hesitate dropping me a message on any platform.
I would like to thank my awesome team in Amdocs’ XDC, who are some of the most professional designers I know.
Thank you for reading.
