Let’s talk motion. Let’s talk process. Let’s talk talking.
I’ve spent a great deal of time over the past couple years generating interactive motion concepts and finding better ways to communicate the intricacies of my output to developers. I’m constantly searching for better ways to maintain the integrity of my work through the migration from concept to code. Any interactive motion designer that’s gone through the process more than once knows that handing over a video file of an After Effects composition and saying, “_Do this,_” to a developer doesn’t always fly.
But does that suggest the developer isn’t doing their job well enough? I’d say no. I would argue that any ensuing discrepancies between concept and execution largely stem from poor communication on the designer’s part. Which is why, based on my experience, I believe that the extra effort required to synthesize motion design into a dev-friendly format will have a tremendous influence on easing the implementation process.
To be clear, designers don’t need to go as far as understanding the appropriate code syntax required to fully implement those custom easing values or string together complex animation sequences. But they do need to know how to break down and clearly articulate each element of their final choreography. We’re all familiar with the classic quandary over whether designers should know how to code their own work, but knowing how to code is different from understanding the limitations to the process. I’m of the persuasion that designers should stay focused on being good at what designers are good at, and allow developers to be good at all the things developers are good at. However, understanding how a concept will be built can be useful in providing the context to better inform design decisions from the start — making it easier to translate during the handoff.
For example: Developers don’t typically work in frames per second. They work in milliseconds. They aren’t interested in the shape of the easing curve in your graph editor. They are interested in the mathematical values that interpolate the property’s transition.
It’s easy for us as designers to view our diligently crafted concepts as precious within the environment of their incubation, but ultimately an After Effects file is no more than a preview of the end product. So think ahead and:
- Set up frame-based project timelines for easy conversion to milliseconds
- Be conscious of how you align the timing of multiple properties in compound animations
- Use existing animation libraries and tools like cubic-bezier.com to determine values for custom easing curves
- Be wise in consolidating repeated values across your product to fall within more optimized global behavior sets
Breaking down motion concepts into relevant and useful segments for beginning values, ending values, transition duration, delay time (if applicable), and easing values, gives developers all the raw information they need to reconstruct the idea.
Handing off your reference videos with these values and perhaps a high-level timeline to map the sequence to (if you think it will help to dispel potential confusion) is guaranteed to get you much closer to a correct execution on the first try. Meet your developer halfway and reap the benefit of your efforts. For reference, Google’s Material Design Guidelines are an excellent resource for seeing a number of these principles in practice.
By designing interactive motion with a developer’s point-of-view in mind, handing off the baton becomes far easier when the time comes. For those who are interested in gaining additional knowledge on this topic, and for those who want to become champions for more effective communications around motion with their own teams, I would consider Rachel Nabors’ guide to “Communicating Animation” as a trustworthy resource — her wise council on the matter has greatly influenced my own process.
But enough about what I think — what other tools, approaches, and communication methods do you use in the motion design process? Let us know in the comments below.