Motion design, the animation of digital content, has become an essential part of our modern interaction with computers. Wherever you look in modern applications, text boxes fly around, elements pop up and menus shrink as you scroll. UX designers have long recognized animations as an essential building block to increase usability and delight the user.
As a visual designer, I have been exploring this topic for several years now. In my personal experience, the transfer from design to development has proven to be critical. As it turned out, it is not so easy to translate the abstract idea of a movement in a designer’s head into an actual application. The form of transfer and type of specification heavily influence efficiency of implementation. An inefficient translation can be frustrating for both the developers and designers involved. How can this be avoided?
Different designers work differently in integrating motion design into their work. Besides the variety of tools (e.g. After Effects, Protio.io, Kite Composer, Framer, Flinto, Principle), the output can vary from loose scribbles to storyboards to frame-accurate animatics. In order to facilitate the communication between development and design despite all the variables, I present some guidelines and basic considerations for the efficient specification of animations in the UX process.
First steps in motion design: Scribble, Storyboard or Animatic?
At the beginning of every motion design we visual designers decide what tools we use to generate which kind of output. While Adobe used to have a near-monopoly position across all areas of design, the last few years have seen rapid change. Every month new programs and plugins for prototyping, animation and UI design appear. Accordingly, it is difficult for me at the moment to commit myself to a specific workflow that always works for me. Instead, I use different tools depending on the application. But it has proven to be a good idea for me to create defined animations and prototypes instead of loose scribbles or storyboards. This adds double value: I can validate whether the animation really works for me as I envisioned it, and then use it to improve communication with the stakeholders.
Delivering precise information
However, it is by no means sufficient to hand over an animation in the form of a video or an image sequence to the developer. The developer can try to translate the animation by eyeballing, but this will often lead to further questions and misunderstandings. It is important to provide additional, clearly defined, precise information in a language that the developer can understand. As I will show, this also has added value for me as a visual designer. Good motion design serves a purpose, provides feedback, tells a story and reflects on the product. For these reasons, it makes sense to also take a bottom-up approach when creating animations, using metaphors, creating patterns, and developing rules.
What expectations does the user have of an object and its behavior? How do I help them to navigate through the interface and ensure continuity with my product? For example, animations can be used as a guide to better coordinate the structural design of my app or give me direct feedback as to whether an action has been performed.
Screen transitions to the right and left can indicate that I’m navigating one level lower or higher, giving my app a more physical feel. Which rules can I generally define for the easing behavior and animation duration?
Objects can be separated from each other by a time delay to indicate that they can be interacted with individually. How do I differentiate between interactive and non-interactive objects and how does the interaction feedback work?
In this way, a fixed construct of consistent elements and rules is created at the beginning of a project, which then functions as the basic framework for all animations. Furthermore, it makes sense to define a library of different temporal behavior patterns in advance, to which only references will be made afterwards. Instead of providing a separate easing curve for each animation, I first create a set of different curves to which I then only refer. The same can be done for animation time spans, delays, repetitions and triggers.
When specifying an animation, all changing parameters in their temporal behavior are determined and captured as accurately as possible.
Parameters for animations
Starting point – Starting point of the animation, default = center of the element.
Opacity – from 0% – 100%.
Size – Specification of width and height
Translation – Relative or absolute position of the element with x and y coordinates (Attention: If the element is not moving linearly, additional information must be provided, e.g. storyboard)
Rotation – number of degrees from the rotation point
Color – transition from color 1 to color 2
Trigger – OnClick, Hover, Scroll position …
Handover of UI animations
The decisive factor for the type of handover is ultimately the effort required for the specification in relation to the value that the designer or developer receives as a result. In principle, the pure text form should be sufficient to describe a large number of animations and should therefore also be the preferred method. In some complex cases, however, such as morphing or merging geometric shapes, an additional description using a storyboard or similar is often required.
The specification in plain text form for this animation could look like this:
on-click, origin-center, duration 200ms, EaseOut, position x485 y354 – x129 y273 (relative x0 y0 – x40 y80), scale w180 h180 – w580 h580 (relative w100% h100% – w400% h400%)
However, this is a very straightforward example. Depending on the complexity of the animation, the text output will be much longer and more difficult to structure.
Conclusion
Today animations are a fundamental building block of UX design and it is important for us designers to develop a sense of how to use them properly. The development of rules and principles and a targeted intention behind every animation is just as much a prerequisite as the targeted decision to refrain from an animation if necessary. The basis for constructive feedback between designers and for communication with the developers is that we find a common language in order to make our collaboration as pleasant as possible. With the current rapid development of tools and working practices in motion design, it remains exciting whether we will achieve standardization for workflow and specification in the future.
