Motion Design Specs – How to Present Animations and Interactions to Developers

Nowadays, a static app UI design is not enough. The Motion Design is no longer future of the UX Design. It is an essential element of digital product creation. If you are designing animations and interactions you should know how to prepare Motion Design Specification for Front-end Developers.

What is UI Motion Design

Motion is an element of the UX Design that brings digital products to life. However, the animation of the UI should not be an artistic expression. You have to think of it as of a part of the UX Design that helps users to understand the solution.

The main purpose of the motion is to show what will happen and guide user’s eye into the action’s destination. It also highlights relationships between elements. What’s more, animation should hide what is happening in the background and finally delight users.

Designer’s tools

The design of the UI’s motion may be done by various tools.

The most popular one – Adobe After Effects gives only ability to create a movie with a sequence of simulated interactions. Adobe software is used often in the community, but we have to remember that it was never the main purpose of After Effects to create the animation of the app. This software is a rich and comprehensive tool for the more artistic animations.

There are apps that are crafted specially to create animated prototypes.

The first worth to mention is Facebook Origami Studio. This tool gives an opportunity to create a highly animated prototype that successfully simulates app.

Flinto is the next impressive tool. It has a possibility to create interactive prototypes with animated transitions, behaviors, gestures and scrolling.

One of the most simple to use tools for macOS is Principle. It is created to build prototypes with rich animations and interactions within a minutes. One of the advantages of Principle is extremely clear animation sequence management in a timeline.

The newest one in the market is the Kite Compositor. This is a powerful animation and prototyping tool. If you would like to create Motion Design mainly for macOS and iOS it is an interesting option.

All of these tools give you a possibility to create an animated video or a prototype and then present it to the developers and stakeholders.

UX Misfit Newsletter

How Developers see animations

When the stakeholder will decide to accept the motion design from the movie or the prototype. It will be the time to start it’s implementation. However, developer will not be able to implement the motion precisely only with mentioned deliverables.

Receiving an artistic vision in a movie or a prototype is not enough. Developer needs to receive precise data of the desired animation behavior.

Implementing an animation in iOS or Android requires providing series of data like the duration, easing, transformation type, initial state and final state of the object. Every developer perceives implementation of Motion Design in these terms.

How to prepare Motion Design specs

Filling the gap in the communication between the Designer and Developer is often a challenging subject. It is necessary to translate the visualization into parameters that will allow the implementation.

I had a sort of spark of inspiration when I was searching for the most efficient way to prepare specs for Developers. I watched the speech from Google I/O 2016. I saw the techniques that helped a team of professionals from Google to create beautifully animated apps in Material Design. Designers in Google have done brilliant work.

Let’s try to improve a bit the specs mentioned by professionals from Mountain View. First, focus on the main requirements and assumptions for the Motion Design specification:

1. Time is the foundation

Every animation and interaction take time. For the developers of Android or iOS, it is ideal to present timing in milliseconds (1 second is 1000 ms). As a designer always prepare specs in this units.

Very often the whole motion is a composition of many objects and types of animation. The good specs should include delays between each sequence.

Google recommends that a whole duration of the motion should be about 300ms. Transitions that exceed 400ms may feel slow.

2. Easing adds life to motion

The linear velocity of the transition often feels not natural. To bring more reality it is necessary to apply some easing curves to the motion.

The animation may accelerate, decelerate or do both depending on a transition phase. This way motion will feel much more natural than mechanical.

iOS and Android provide several predefined easing curves that will help developers implement the requested animation faster. If you are curious which curves you may use quickly you will find some additional information for Material Design and iOS

Off course every easing is, in the end, a mathematical equation called polynomial. Front-end developer should be able to create all types of the easing curve in code. Here are the helpful samples from Victor Laskin’s Blog.

Easing curve used for the animation of the particular element is the must have information in the specs.

3. Type of transformation reveals possibilities

To create good motion it is necessary to be conscious of the types of affine transformations available in the UI motion:

Translation – changing view position in X or Y axis

Scaling – changing the scale of objects width, height or both

Rotation – rotating object around X, Y or even Z axis

There is also a possibility to change opacity (alpha property) and color of an object.

The combination of these types may give outstanding results. Your specification has to include a description of the transformation type.

4. Transformation parameters ensures constraints

Every animation will be useless if we will not provide exact values that will inform an app about the scale of the motion.

It is good to provide values in points for translation (pt for iOS and dp for Android), in the percentage value (for example for scaling or opacity) and in the degrees or radians (rotation).

Always consult with your team which types of values will be useful for them.

5. Animated object is a must

Finally your specs should include a short information about an element which is interacting in a particular moment.

The sample Motion Design specs

When you put all of the mentioned parameters together you will probably come to a conclusion that the best way of to present this type of specs is a chart.

Let’s figure out how it should look like. The X axis of the chart should be a time in milliseconds. Next, Y axis should present the animation elements in sequences.

These assumptions will result in the presentation of the animation duration of the elements.

When we think of the easing curves, a perfect solution to include this information in specs may be a color of the particular duration. A simple guideline near the chart should explain which one is responsible for each easing.

A market standard?

Recently I was surprised when some mobile design agencies admit that they do not provide any specs or guidelines for the UI motion. In their opinion, the movie file with an animation should be enough to implement successfully motion of the UI. Such statements show that Motion Design of the apps is not treated professionally yet.

As I mentioned earlier, Google had done a great job in the matter of specs for Motion Design in their apps. Specification mentioned in the speech from Google I/O should be an inspiration for an every designer to prepare this type of assets.

To sum up

If we would like to see more beautifully animated User Interfaces every animation or animated interaction created by Designer should include specs for Developers. Without any doubt, Motion Design Specification should be a market standard. What’s your opinion on this matter?

If you would like to start preparing UI Motion Design Specs, check out the article with Sketch file Template. It will help you prepare guides for developers efficiently:

Thank you for the article. This is the first time I’ve seen the subject of motion spec handoff brought up.

It does seem, however, that this is a labor-intensive way to communicate specs to developers, assuming the motion was already prototyped in some tool. In some cases this approach would make sense (e.g. large consumer facing app with significant UX resources), but in other scenarios this could take too long. I’d love to hear what others have done. It would also be awesome if some of the prototyping tools that fully support animation would provide a “spec export” in this format.

“Specs export” done directly from animation/prototyping app would be perfect. Unfortunately I have not seen anything like that yet.

Regarding the other motion specs styles, I know that Google used simple plain text guidelines to describe animation designed for the first Material Design apps. If you would like to know how it looked like, here is the blog post: http://sebastien-gabriel.com/rca-appendix/ In my opinion it is a bit faster to write down those specification, but it is not as clear and readable as the charts.