Communicating Animation

Consistent animation is crucial to both branding and UX. Interfaces obey laws of “design physics”; keeping animation consistent throughout an experience envelops users in an illusion of life, of reality. Animations that step out of line disrupt that flow and feel sloppy or jarring. But because animation sits squarely at the intersection of design, development, and UX, achieving consistency presents unique challenges:

• Communication issues make it hard for siloed teams to understand and tackle animations together.
• Inadequate deliverables prevent developers from moving forward quickly.
• Lack of respect for and deference to fellow team members leads to lopsided implementations that privilege some voices at the expense of others. When it comes to animation, it’s important for everyone to be heard.

Including animations in our style guides and design systems is a great place to start. However, this is relatively new territory, and most animation documentation initiatives seem to be driven by either development or design. In an ideal world, developers and designers would live in harmony and collaboration, but all too often the two houses exist in isolation from each other.

Most examples of animation in documentation reflect this rift by falling into one of two categories: thematic and educational, as seen in Google’s Material Design guidelines; or granular and explicit, as displayed in Salesforce’s Lightning Design System. Designers want to provide guidance and overarching themes, as well as educational materials, in an effort to raise the profile of animation both within a company and within the larger web design and development communities. Meanwhile, developers aspire to define and dictate animation for maintainability and consistency.

This contrast reflects the needs of each group. Designers want to know the underlying principles of motion design driving their application; developers want to know how to build that design to spec. These interests are not at odds with each other—rather, they form incomplete halves of a greater whole:

• Documentation details what’s there and why.
• Defaults offer building blocks and rules for spinning up new projects.
• Unity provides a common language and choreography.
• Guidance empowers future designers to make smart decisions.

As of this writing, there is no Ultimate Animation Style Guide/Pattern/Tile/Whatever example that combines all of these elements perfectly. There may never be an animation-style-guide pattern that satisfies everyone. Some organizations may need more of some of the above components than others, depending on the project and the animation or development literacy of the team. But all approaches share features that we can combine to create the Ultimate Animation Documentation for our own teams. Let’s have a look.

Deliverables#section2

Deliverables are supposed to round off the design process, but I often find it helpful to start with what developers want and need. Some companies have designers who build prototypes in code. Developers then find it easy to go into the code and grab the variables needed to reproduce the UI animations. But not all workflows look like this, and many motion designers will rightly argue that the very act of animating code-first limits the ideation process.

That’s why, at many companies, designers create animations in After Effects or Photoshop and then hand them off to developers. The developers must then pick apart these videos and gifs to determine what is changing at what rate. This makes the burden of implementation especially heavy for the developer, giving animation a reputation for “taking too long to prioritize.”

I myself once had to spend six hours converting an animated GIF to SVG by eyeballing it. If the designer had provided me with the necessary values, I could have recreated the animation perfectly in thirty minutes, tops. We’ll look at these values—easing, timing, and properties—next. For the sake of simplicity and consistency, we should include them in our documentation and reuse them as much as possible across our systems.

Easing#section3

Easing describes the rate at which something changes over a period of time. It has its roots in traditional studio animation, where it was called “cushioning” or “slowing.” Easings are shorthand for rates of acceleration, deceleration, and bounces. We can invoke generic easings with CSS via keywords like “ease-in” and “ease-out,” but when everyone uses the same defaults, everyone’s designs start to look and feel the same.

Easings provide an opportunity for us to set our UI apart from others in a very subtle way. We want custom easings that reinforce our brand—be it professional, fun, elegant, or even dark. And that’s what cubic-bezier curves were created for. Cubic-bezier curves are a set of numbers we can pass to CSS and JavaScript animation libraries to tell them how we want the animation to change over its allotted timeline. We can get some starting points at sites like easings.net or create our own using the browser’s developer tools.

It’s tempting to make one cubic-bezier curve to rule them all, but what we really want is an array of several curves for different purposes:

• Human-initiated interactions feel faster and more natural if they respond immediately. A deceleration (moving from fast to slow), or ease-out, provides immediate feedback that tapers off.
• System reactions are less alarming if their curve is accelerated, moving from slow to fast, or what we call ease-in.
• Fades and color changes often look best with a more constant curve, but you could purposely buck that to express your aesthetic values.

Most design systems benefit by specifying at least an ease-out, an ease-in, and a fade curve.

Timing#section4

Easings are a high-visibility return on investment. But animation can’t happen without a duration. On the Lightning Design System, I worked with Amy Lee, who also happens to be a musician. In a brilliant example of genius occurring in the overlap of disparate fields, she came up with the concept of timing scales: a set of time values that align at various combinations.

The concept is similar to modular scales in typography: all values are related, and if you combine them with a vertical rhythm, a piece exhibits overall harmony. You can generate a timing scale the same way you generate a typographic scale.

There are upper and lower limits. While the human eye can perceive images in as little as 13 milliseconds, it takes us between 70 and 700 milliseconds to move our eyes according to the Human Processor Model. 200–300 millisecond values typically become the workhorses of a timing scale, from button depresses to secondary animations. (The persistence of this time range across game and web development is especially interesting in light of recent research suggesting we experience the world in 400 millisecond “chunks.”) Shorter durations work better for color changes and fades, which the human eye picks up readily. Longer durations are better for larger fields of change, like page transitions, or motions that occur over longer distances, like a drag-and-drop interaction or menu slide-out over a large screen.

It’s a good idea to define durations in milliseconds rather than seconds. While most animation libraries can accept seconds and milliseconds, JavaScript timers and the Web Animations API take only milliseconds. Also, some people may find it easier to work with zeros than decimals (although that might be more of a tabs versus spaces argument).

Properties#section5

Properties describe what is being animated. Currently in web animation, the most performant things to animate are opacity and transforms (scale, distance, rotation). But there will be times when we want to animate less performant things like color or—heaven forfend!—height. Browsers are working hard to improve their animation performance, so while it’s great to try to stick to transform and opacity, don’t be afraid to push technology with art where you can get away with it.

Knowing the properties we want to animate comes in handy when communicating animations with storyboards and specs and when we’re creating our project’s very own animation vocabulary.

Creating an Animation Language#section6

We combine these three components—easing, timing, and properties—to create vocabularies of words like “pop,” “fade,” and “slide.” Many of these expressions start as friendly onomatopoeias: swoosh, zoom, plonk, boom. And sometimes colleagues will, say, hold a sound longer to indicate extended duration: “Can you make it more like voooooosh and less like voosh?” It makes sense to “pave the cowpaths” and adopt words like these when constructing our own animation vocabularies.

Vocabularies are granular. You can layer these microanimations to create macroanimations—for instance, a modal that fades onto the screen then pops to grab user attention.

These words might seem arbitrary at first, but they yield huge benefits when it comes time to document our visual deliverables with text.

Communicating Visually#section7

There are three ways to communicate animation: storyboards, animatics, and prototypes. All of them contain a visual component, but only storyboards include words. Words are one of the lowest common denominators of digital human information exchange—capable of being read out loud, indexed by search engines, translated by machines. In many cases these words are the key to conveying animation deliverables, so it makes sense to start with storyboards.

Storyboards#section8

Disney Studios invented storyboards for working on feature-length animation films, and it wasn’t long before Hollywood started using them, too. Storyboards let disparate teams get an overview of a linear narrative. They reduce time spent on dead-end shots and help directors and writers visualize the final story, and edit it on the fly. These days, storyboards are used not only in cinema but also in game design and interaction development.

These storyboards can range from very informal (on a small-team interaction-design project where everyone follows each stage of development closely) to very detailed and particular (for specifications and audits). One problem I have as a consultant is that I find it difficult to embed videos or GIFs in PDFs to hand to managers as a way of explaining where animation problems occur. So for long-term storage, I include a storyboard.

This storyboard was part of a motion-design audit for a large project where I needed to leave the client with actionables to include in their next sprint.

Storyboards use words and illustrations to represent interactions and animations. Every animated interaction can be divided into a “before” shot and an “after” shot; it’s up to us to illustrate the in-between shot to demonstrate how we get from one to the other. Language helps us clarify why these changes are happening. Using words like this is a powerful thinking tool. Justifying animations verbally helps us sort necessary animations we can defend from ones that are perhaps less mission-critical.

Storyboarding software, most of which is geared toward cinema, is simultaneously insufficient and overkill for web development collaboration. Teams often have more fun and collaborate better with good old index cards and Post-its. I’ve written about a more formal approach to my storyboarding techniques, and you can download my storyboarding template to get started.

Animatics#section9

If a picture is worth a thousand words, an animation is worth ten thousand meetings. Storyboards, sadly, can’t show us how something “feels” on the screen or under the thumb. Once again, studio animation provides a solution in the form of animatics, videos of the storyboard set to an audio track that can be screen-tested with an audience or presented to investors as proof of progress. We can also make small videos or GIFs with our wireframes and storyboards that demonstrate how they work.

Do not throw these mini videos over the fence to developers. Finalize animatics by combining them with the deliverables developers crave: easing, duration, and properties. At most, an animatic is a measuring stick against which we compare the final, implemented animation. And the two will only match 100 percent if we provide our developers with the inputs necessary to duplicate the original.

For creating animatics, AfterEffects is the software of choice in the motion design industry. Web designers may be more accustomed to creating animatic-like demos in Keynote to be clicked through in meetings. These can be recorded with screencasting software like Quicktime or Camtasia. And some visual prototyping tools like Principle export to video, achieving two things at once.

Prototypes#section10

Animatics can be screen-tested on an audience, but screen-testing works best for passive media. The web is interactive: people interact with designs, which in turn react to them. There’s no way to test these reactions with storyboards or videos. When we want to be sure of how people will respond to a design, we want prototypes.

There are two approaches to prototypes: coded prototypes and prototyping software. Developers tend to prefer the former, often leaning on frameworks like framer.js and Zurb’s Foundation; designers prefer the latter, in the form of software like Invision App and UX Pin. Both approaches require team members to invest time in learning a new system, thus increasing the commitment factor.

Most prototyping software with animation features, like Pixate and Principle, is app-oriented. But the web is catching up with products like UXPin, and web and native prototyping powerhouse Invision has demonstrated its commitment to improving animation tooling with its purchase of Easee.

Coded prototypes, unlike storyboards, are terrible for documentation: only code-savvy team members can read them, and the files must be organized and sometimes compiled or served before inspection. An external agency would struggle to deliver a fully branded experience riffing off a pile of non-production code.

Pick two#section11

If we rely on storyboards, animatics, or prototypes alone, we can’t hope to communicate animation clearly, effectively, or sustainably. But if we combine them, they work great: a demo next to a set of deliverables; a storyboard with a video. Such combinations work well for documentation and also sometimes for offering animation boilerplates.

Animation as a team sport#section12

Many animation documents are created in the hopes that “if you write it, they will follow.” We hope our coworkers will read our sage advice and start preaching the animation gospel; we hope they’ll copy our animation deliverables perfectly for every button, gesture, and loading spinner.

In practice, though, it’s extremely rare for even half of a team to care as passionately about animation as the person writing the docs. While education and guidelines are fantastic in principle, they are a wasted effort if no one cares. Here are some quick ways to get our teammates on board:

• Group documentation. Having a documentation format that everyone can contribute to—and then having people contribute even just a few words—helps them feel like this is their baby, too.
• Team tweening exercises. I use these exercises in training to help get siloed teams collaborating. Take “before” and “after” wireframes, and give everyone index cards to brainstorm all the possible animations they could use in between those states to get from point A to point B.

• Cultivate and champion. Teams without motion and animation champions can’t sustain their animations over the long run. Someone has to grow the love for animation and make it second nature to think about it, same way we think about color or fonts. Otherwise, animation risks being sidelined the way accessibility and user testing often are. Many organizations assume an initial effort is sufficient to address what should become an integral part of their design process.
• Have a coconspirator or two. We should always be on the lookout for coconspirators. One champion isn’t enough. Eventually we all move on to other projects, and a healthy system is one that can function when one of its pieces goes missing.
• Do it anyway. Sometimes people just have to see the difference animation makes to believe it. You can ask for forgiveness later.

A template library will need different documentation than, say, an interactive story app. What matters is clearly recording and communicating those deliverables and cultivating a concern for animation among our peers. People fear what they don’t understand, and they fear change. Education, communication, and collaboration turn that fear into enthusiasm and goodwill.

There is no one right way to document animation. But when we collaborate with our teams, together we will find the right way forward. Don’t be the lone animation wolf; find or found an animation pack. Recruit other animation wonks from different areas like UX, front-end development, data visualization, design, and marketing. Diverse views will strengthen how we approach animation and help rally more support from other corners. Together, we can all find our own “way of animation” that works best for us.