We are very please to bring you the first post of our new Design team member Paul. He joined us beginning of this year and immediately established himself as a motion design expert inside the team. We asked him to share some of his insights and methods in a post. Enjoy the read!

Visualising the specifications of a motion design

Animation creates energy within an interface and lets the user know what’s happening before, during and after an action

— IBM

Motion is an inescapable element of design these days. The days that motion design sat squarely in the domain of animators and VFX specialists are long gone. Major companies such as Google and IBM treat motion as a key part of their design guidelines. Designers around the globe have come to the realisation that motion can be much more than a fanciful supplement to a user interface. It can be an incredibly powerful tool used to guide the user to where we want or need them to go.

{{divider}}

Closing the knowledge gap

As a result of motion design’s recognition as powerful tool to enhance the user experience, the front pages of design-focused websites are at any one time filled with a dozen or so animated GIFs, featuring elements that slide, jump or scale in and out the screen. You might take a look at these and find some inspiration and consequently set off to create a similar animation for a project of your own.

You toil for a few hours (if not days) in your prototyping tool of choice, be it Principle, Flinto, After Effects or whatnot. And in the end, you have this snazzy animation that you think will be perfect for your project.

So you render the video of the animation, double check it to make sure everything is moving at the right pace and time, and store it somewhere safe. There you go. All done. Now you just need to send it over to your engineering team and it'll be implemented in no time. Great!
Cue the engineer. They get handed a video that's barely a couple of seconds long, maybe a vague description of the animation, but that's probably all. Their instructions?

Make it look like this.

That's it. That's all they get. A video or GIF and the instructions to replicate the animation. Unsurprisingly, even the most experienced of engineers are often hesitant to work on any form of motion design. It takes too much time, isn't worth the effort, they complain.

And rightfully so. Imagine being handed a brush, some paint, a blank canvas and a grainy printout of a Picasso. Your instructions? Make it look like this. You'd be pissed off too, wouldn't you?

Enter the animation graph

Any designer (or engineer) who's worked on motion in a team has probably come across the scenario outline above. You might've wondered if there was a better solution for handing over motion designs. A better solution to collaboratively work on building and shipping your animation.

Enter the animation graph.

An animation graph (or motion graph, if you will) is a visual representation of the timeline of your animation. It is to your animation what a legend is to a map. An insightful companion that will make it easier to grasp the specifics. The graph allows you to quickly and easily answer a lot of questions concerning the animation, such as:

• What element is being changed?
• What property (e.g. opacity, position, angle) of the element is affected?
• When does the animation start and end?
• What animation-timing curve is being applied?

At a quick glance, you can gather a lot of information from the graph, without having to dig through the often convoluted timeline of whatever prototyping or animation tool is being used.

In practice

The video (or GIF)

At the core of the motion design handover sits the video. Or GIF, in this case. It's a quick and easy demonstration of what you're trying to achieve and can be relied upon as a reference while you're building or reviewing the animation.

{{divider}}

The specifications

The graph essentially serves as a companion to the animation. It's the nitty- gritty of your motion design. Using this, engineers can nail the specifics of the animation without having to even think about things like prototyping tools or After Effects timelines. There's no need to hover over their shoulder to make sure everything's pixel-perfect. The graph defines which elements are being changed, so that no parts of the animation are left out.

Using the graph, a couple of things can be established:

• The animation is staggered. There's two separate parts to the animation, starting at respectively 0 ms and 250 ms.
• Three different animation-timing curves being applied to the elements in motion: ease-in, ease-out and a standard curve.
• Four different elements are affected by this animation: two radio buttons, the title of the second card and lastly, the content of the second card.
• Likewise, four properties are affected: fill, opacity, Y position and scale.

Assuming the curves are set up in advance, engineers need only set the transition start and duration, apply the pre-defined curve and the affected property.

The graph doesn't specify the exact changes though, e.g. change opacity from 0% to 100% or Y-position from 450 to 550. These still need to be either documented specifically by the designer or eyeballed by the engineer. But it's a hell of a lot better than "Make it look like this".

‍