Designers, start trusting developers with your motions
From full-screen moving images to small hover effects, touches of animation are popping up everywhere. We could even dare saying that motion is the new black. Animation is trendy, fun and user friendly. That’s why we, as designers, want them!
The problem here? Animations are not easy to describe and specify. This tends to turn the development process into an endless struggle filled with misunderstandings and frustrations.
For our ideas to be brought to life, we will need to provide developers with the clearest specifications possible. And that implies having a strong understanding of what is doable and speaking the same language.
A couple of months ago, our team of developers was feeling frustration while working with an external designer. No doubt he had great ideas for his animations. But he did not find the way to share them with us. So designs went back and forth. Energy and time were wasted and motivation sunk.
In the digital era, design and software development constantly overlap. This is why we created a guideline for designers to write animations specs that mean something to developers. It is no magic recipe, but we believe it is a good start!
This is what we now use internally and when working with external collaborators. And it has made our life as a team so much easier. We recognize our designs and feel our work is respected. Developers know where they’re heading, save time and deal with grateful designers, and that’s not a minor deal!
Before getting into any further details and precise specs, take the time to describe your animation in simple and clear words. The key? Keep it simple!
So, designers, once your design is ready (mock up, prototype, etc.) and before starting to work on animations: make sure everyone knows which elements are going to be animated and what their expected behaviour is.
A simple example: [Element] Violet square, [Effect] rise (scaling + opacity).
If you’re not sure how to name the effect, here is a good source that can be used as a shared reference among your team: Animate.css.
In addition to the short description, it is useful to share a visual with the developer. There are two different options, depending on your ability to animate:
Storyboard: It contains a simple sequence of drawings with a super simple caption. What elements absolutely need to be included? Timing and directions.
Animatic: Basically, it is just the animated version of the storyboard. It leaves out the necessity to read the storyboard and offers immediate visualization.
So, at that point, you have described and sketched your animation. You have confirmed with the team that they understand what you’re expecting and they have confirmed with you that there is a reasonable way to make it happen.
Well, then it’s time to make their job easier by providing precise information about these animations. Starting with Properties and Values.
We are going to focus on CSS’ properties. Although there are more, we’ll list the properties that are most often animated and tell you how to specify them.
By the way: it is not necessary to specify them all. By default, if no value is specified, the property is not going to change.
Origin point: Define a starting point for all the properties, from which all animations will start. By default it’s set to the center of the element.
Opacity (from 0% to 100%)
Color (from color#1 to color#2)
Scale (from 0 to x, being 1 the 100%): In case the scale is not proportional, you can specify: scaleX(value); scaleY(value), being 0 the smallest size possible, and 1 the element’s complete size.
Translation: amount of space to move from a given position. In case you want a particular path, you should attach a storyboard.
Rotation: Define the angle from the rotation point. You should specify if the rotation shall return to the original state.
The timing is the time it takes for the animation to be completed. The animation should be fast enough not to keep the user waiting but slow enough for the transition to be understood and consciously perceived.
Here is what you’ll need to specify:
Duration: defined in milliseconds
Delay: the time it’s going to take to start
Iteration-Count: number of times the animation will be repeated (from 0 to infinite)
The easing curve is a line that defines the acceleration pattern. There are literally an infinite number of ‘easings’ that you can create and implement. Here are the most common shapes of easing curves:
Linear (This is the default value)
Ease In (gives the illusion of starting slow and speeding up)
Ease Out (gives illusion of starting fast and slowing down)
Ease In Out (elements quickly accelerate and decelerate)
* Think of vertical = fast and horizontal = slow.
Cubic-Bezier: With this tool you will be able to create custom speed and compare it with standard curves’ shapes. You can see how the speed is moving instantly here: http://cubic-bezier.com/. The best part? It will generate the values for you!
* Depending on the animations, all properties can share the same easing curve and timing or have their own. In that case, the specs’ sheet should be more detailed and specify properties one by one.
The relation between designers and developers is precious. It is the key to the success of all digitally-intended designs. And even more when those are animated.
So it’s high time we find a common language and start making each other lives’ as easy and enjoyable as possible! These tips proved useful to us, but there is definitely more than one way to smoothen the collaborative process. And we’re always interested in exploring options.
So let us know your thoughts and ideas in the comments!