Working Together: UX Motion Specs for Design and Development
How motion specs make it easier for designers and developers to bring user experiences to life
One of the ways we can engage and delight our users is through motion. Motion can guide the user through their experience and bring it to life. In particular, UX motion is the integration of motion into the user experience. It’s the animation that happens when a side panel slides out or content fades in.
Designers and developers should work together from the beginning of a product build to include motion in their user experience. But, don’t worry if you’re working on a product already in production — it’s not too late.
It can be challenging for designers and developers to work on motion together. Developers use a variety of motion libraries and CSS animations to implement motion. Motion designers, on the other hand, usually work with programs like InVision Studio, Adobe After Effects, and Flinto. Sometimes designers are able to use the same libraries as developers, but many libraries are only meant for developers.
Both developers and designers should communicate on UX motion the same way they do when creating any design: conduct and synthesize research, make prototypes, share in playbacks, iterate on their work, and receive feedback along the way until our products are the best they can be.
Motion specs facilitate that conversation by providing exactly what a developer needs to implement the motion a designer created. They make it easier to adjust at every iteration, and give feedback in a clear and concise way.
Which brings us to UX motion specs and how developers and designers can work together to build motion into their products.
UX Motion Specs
These 4 specs, element, transformation, duration, and motion curve, are the basis of what developers need to implement UX motion. I’ll elaborate a little more on what that means and how well they’ve worked for me. You’ll want to provide each of these specs for a single motion, and for each motion in a series of motions (choreography).
It’s also important to note that for animations that are not UX motion (for example, data points that look like movable dots), other specs and libraries will probably be required beyond what’s listed here. Additional specs might vary greatly depending on the intended motion.
Element
Simply put, the element is the piece that will be animated. This could be a group of elements, a component, or the background of a whole page. It’s important for designers to be clear with developers on what that element is, either with an animated mockup or another static visual representation like a picture.
The property is a part of the element spec that specifies what is going to change about the element. For example, a change in the color, vertical position, or opacity is a property. Be sure to mention both the element and property. For example, side panel position.
Choreography includes multiple pieces moving together, often with multiple transformations on one element (ex: a fade out as the element moves off screen). It’s important to consider how these elements work together in your specs, and you’ll need to provide the full specs for each animation, along with how they play together. See “additional specs” below for more info on conveying choreography.
Transformation
Transformation is the animation, or motion itself. The element property might give you context about possible animations to choose from. For example, a background can change color, but unless you give it a size, it can’t really move across the page or rotate.
Standard motion transformations include move, fade, scale, and rotate. Developers need the specifics of which transformation and what the change is, for example, fade to black, rotate 360 degrees, move 300 px left, or scale 100%. Whether you use pixels, percentages, or rems should also be determined through a discussion between designers and developers ahead of time.
Let’s talk about accessibility. Keep in mind that animations that move across more than 1/3 of a page can cause accessibility issues for users with vestibular disorders, and anything that flashes can trigger seizures for people with epilepsy. In general, a bounce, flash, or something similar should not happen more than 3 times.
Duration
The duration is how long the individual animation will last. For example, a page might fade to an overlay in 0.4 seconds, or 400 milliseconds. You can use built-in tools to determine a duration. This is probably the most flexible of the specs here, so choose a timing that feels natural for the movement but won’t throw off your user.
Note that large elements should not move too quickly, as that could also be an accessibility issue. UX motion typically does not last for more than 1 second, and even that is considered a little long, though animations other than UX motion can last longer. For more information on how long animations should take, read about the Doherty Threshold, which states that user feedback should occur within 400ms to hold their attention and increase their productivity.
A delay is an additional time spec that is very important if you have multiple animations happening at once. Most likely, one starts after the other, and the delay between them is something developers need be aware of. If the person designing this animation is not very familiar with motion design, they can work with their developer to prototype and find a pacing that works. Start with the order of the animations and use the choreography to determine delays.
Motion Curve
Motion curves determine the rate at which elements move, which usually changes over time. An object might start moving slow, and then speed up, or vice versa.
There are many different kinds of motion curves, and in general they can make movements feel more natural than an element moving across a page at the same speed. A typical example of a motion curve is ease. There are many great resources that explain it well (this Medium article, for example) but when it comes to specs, developers need to know what curve to apply.
The software you use might have some standard curves it can apply, or you can use a library or package to align on what motion curves you’re using rather than writing a custom one. For example, we use Carbon Motion, an open-source motion package built by IBM as part of the Carbon Design System. The standard productive bezier curve from Carbon Motion looks like cubic-bezier(0.2, 0, 0.38, 0.9) in CSS and InVision Studio, but in After Effects it will be written as outgoing 20%, incoming 62%.
I recommend using a package with motion curves to align on what specs you’re using instead of writing a custom one, as your designer can plug in the specs to their animation software, and your developer can use a token from the package or plug in the specs themselves.
Possible additional specs
- Motion libraries:
These are the libraries I’ve mentioned above, like Carbon Motion. This helps us align on what specs we’re using and makes our work more consistent and accurate. Aligning on motion curves via a library has made motion much easier to implement for me. - Overall choreography:
Providing an overall motion spec chart like this one helps visualize what will happen, and when. This method has worked particularly well to help me visualize choreography as a reference. That said, it’s more work for designers, and a screenshot of InVision Studio’s timeline or a simple text list might be faster. This should be accompanied by a video or interactive prototype of what the animation looks like.
Example Code
Here’s how I implemented motion on a side panel. In this example, the side panel content will slide in after the side panel itself.
First, I made a side panel container in the HTML, which is basically the rectangle that will move in and out of view. In the CSS styling, I wrote this line to dictate how the side panel will move:
transform: translateX(448px);
which means the transformation is a horizontal translation 448 pixels to the right. I also told it to take 300ms and use the carbon motion standard easing curve.
transition: 300ms carbon — motion(entrance, expressive);
I also placed another container around the content in the side panel. Based on the specs I had, the side panel content should move the same way as the side panel, but it should come in afterwards, with a delay of 20ms. So when I take all the animation CSS for that side panel content, I have:
transform: translateX(448px);
transition: 300ms carbon — motion(standard, expressive);
transition-delay: 20ms;
Let me highlight where each of those specs we talked about comes into play.
Here’s what that code looks like in action.
Hopefully this can help visualize how developers use these specs in CSS.
It’s crucial for designers and developers to work together when implementing UX motion. When they have the proper specs and communication to do so, magic happens.
Resources
Here are a few resources to help you get started with UX Motion.
A quick note: I work at IBM, and I recommend an open-source tool made by IBM in this article. The Carbon Design System and Carbon Motion are available to anyone outside of IBM, and my recommendation is based on my everyday use and the ease of use I’ve had with the tool. Additionally, this article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
