The SpoolCast
with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Connect

Share This Show

Episode #266
Rachel Nabors - Using Animation to Enhance Your UX

Listen Now

Animation in interfaces has traditionally been seen as purely decorative and unnecessary. There are real accessibility and usability concerns associated with a heavy reliance on Flash. Advances in CSS have allowed for sophisticated animations and transitions that actually add to the experience. In fact, a well timed transition can help alleviate the cognitive load on users.

Show Notes

Rachel Nabors is an artist, animator, and founder of the Portland-based outfit, Tin Magpie. In her virtual seminar, Improve UX with Animation, she covers six principles of animation to use when designing your interactions. She received a slew of questions from the audience during the live seminar. In this podcast she returns, joining Adam Churchill, to address some of those.

How do you decide when to incorporate animation within a design project?

At what point do you discuss how the animation is going to be executed?

Are there animation tools for designers who can’t code?

Is there a shorthand that exists for specifying common animations?

How do you manage easings and durations across a team of designers?

Are there frameworks that can be applied across different interfaces?

What do you use for prototyping animations?

Full Transcript

Adam Churchill: Hey, everyone. Welcome to another episode of the "SpoolCast." Recently, Rachel Nabors presented a wonderful virtual seminar to our UIE audience. It's called "Improve UX with Animation." Now the recording of this seminar along with 210 other UX seminars is now part of UIE's all you can learn.

Animation often gets a bad rap for being nothing more than decorative and sometimes even in poor taste. It turns out animation can add value to the digital world by making interactions more intuitive, interesting, and seductive. In her seminar, Rachel showed her audience how animation can benefit user experience.

In today's podcast, she's offered to come back and talk a bit more about it, and even answer some of the questions that our audience had that we just didn't get to.

Hey, Rachel. Thanks for coming back.

Rachel Nabors: Hey, Adam. Thanks for having me.

Adam: For those that weren't with us for your seminar, can you give us a bit of an overview on what you talked about?

Rachel: Sure thing. First, we started off by going over the animation theory. There are studies going all the way back to the 1990s. Fascinating research papers about how transitions and animations can be used in operating systems to help offload a lot of the cognitive work into the visual cortex.

We talked quite a bit about that. I feel that's a really big justification for why you should be considering animation early on in the workflow. Then we got into six awesome principles of animation that you should keep in mind when you are working with your interactions causality, feedback, location, progression, physics, transition and how to combine them to reinforce in interactions, relationships, and structure, and cause and effect.

In the second part, we get into the best practices you should keep in mind when you are using animations. You don't throw off users by animating too much. Finally we get into where animation fits in your process, and how to spot good candidates for things that could be animated or transitioned.

Adam: Excellent, the second part of your presentation really spoke a lot about, "I like this idea of animation. I get that I should be using it. How do I work it into my process?" The team from Electronic Ink asks, "Do you have a preferred process for deciding when to incorporate animation within a design project?"

Rachel: In most people's processes they start with a lot of research work at least we hope that that's how people are starting their design project. They start by researching the users. Finding out exactly what you're trying to do with your project.

This is a good time also to start thinking about animation. Right around the time that you've figured out what the body of your information architecture is going to look like, and what your users tasks are going to be. Right around here that you are going to start paying attention to changes in state like an example would be when going from boating to loaded.

If you have lots of heavy information that's going to take time that probably could use some animated indicator. You also want to look for changes in information environment, and users switching topics, switching domains like going from invoices to expenses.

Also look for changes in task, going from reading to writing, to searching for example. Those are three different tasks and they require very different environments, and transitioning between those environments will provide about our experience, and if you just jump all over the place.

Lastly, any time there's a change in content, things appearing or disappearing from the page. In existing sites you want to look for page loads and repaints, Ajax calls. If the user is going from one place to another, or information is being loaded and unloaded from the page. Those are pretty easy tells.

Adam: Curt wanted to know a bit more about when you've got people thinking about these animations and you actually have an opportunity to plan them early. At what point do you discuss how the animation is going to be executed? For example deciding on the technology you are going to use to do it.

Rachel: That's a very good question. It depends actually on how big your team is. Now for large companies, you typically want to have your front-end developers available to inspect your prototypes once you get to the prototyping stage.

Ideally, after you've done all your research and you've done your studies and you start wire-framing, prototyping and story-boarding, not in that order. Usually you start with wire-frames and storyboards, and then you start making little prototypes.

Prototypes are then passed around to different stakeholders and different developers, and also you use them to test on actual users to see if you're sniffing up the right tree. Now in a large company, you want front-end developers to be looking at those prototypes and going, "Yes. We could achieve this animation by using da, da, da, da framework, or we could extend our current framework to achieve this in this way."

That's when you want to have developers poking their noses in. However if you are in a smaller company, and you are experimenting with animation say in a branch or copy of your product, you'll want to start discussing this with your coders why you are actually story-boarding.

It would be way more collaborative. It will be informal. You'll probably have technology informing your design a lot more than if you are on that much more formal a larger company process. That's not necessarily a bad thing. Both have their pros and their cons.

With larger companies things feel less collaborative and more dictatorial. That also means the designers have a finer hold on how things are supposed to perform. The develop arc is that it can lead to miscommunications between developers and designers. Both have their pluses and their minuses.

Adam: Patricia is wondering if you can talk a bit about animation tools that exist for designers who can't code.

Rachel: Patricia, we are in a good space right now, because a lot of companies have realized that motion is something where more designers are into especially because we are seeing more prototyping tools for apps and Web apps. In the app environment, animation is already very common.

When these companies start extending out these prototyping tools to incorporate the Web, they still have all those animation features. Right now, what I'm hearing most about when I interview companies is InVision and UXPin. They are two surfaces that you can use to build out animation. Not just animation, but you can actually design an entire website inside them.

Create user flows and shareable prototypes and they have animation features. This is a great way you can get the entire team in and collaborating with it. There's also Flinto and Pixate. They are more app oriented. They were designed originally for apps.

You are going to see a lot more boiler plate for app type interactions and whereas InVision and UXPin encompass the full spectrum of devices. The pros of these are that they are built for teams. They have lots of sharing features built into them. They support a lot of different workflows, a lot of different software.

You can import things directly from Photoshop or sketch. The cons are that they are services. They require heavy learning investment. You have to try them out like grab a person and say, "Hey, you, I want you to go try out all these different things and find the one you think works best for our companies requirements."

They come back to you and say, "We are going to need x number of licenses," so their commitment intents. If you are not feeling committal that can be an issue, or if everyone's like you are on a smaller team, and everybody very much has their own processes.

If they rather adhere to having one person use one of these might be source of defeating. The other options are Google Web Designer which is design for making ads, but the nice part is that it's free. It does let you create very tiny example animations and export them directly to code like you can just put up on a server.

There is Adobe's Edge Animate, which has the very familiar flash type interface that we've all grown up with. For that reason, it's very easy for designers to pick up. They have great timeline tools. The cons are that they're less feature-rich. They are better for smaller one offs and clarifications, but they don't take over a design process.

All of these by the way do not create product-ready code. These are strictly for prototyping and sharing. You wouldn't want to take any of these things and just put them into production.

Adam: We had a bunch of folks that were asking about short hand that might be used for specifying common animations. Got anything for that? What do you suggest?

Rachel: Absolutely, good question. When it comes to especially when you are documenting animations, it can be a good idea to put those animations into sentences. For instance, for me, I tend to write out my animations with a formula that goes you list the trailing event, the thing that's being animated, the property.

How long the animation lasts, and what your easing is. That would be on load the width goes from 25 percent to 100 percent using easing over 300 milliseconds. That's the way I write it out in documentation. It makes sense to front-end developers and it's still legible for designers as well.

Adam: Rachel, I have a question about easings. You spent some time talking about those in the presentations. How do you keep a team of designers and implementers from each using different easings and durations on every little thing that they're trying to put in play? Isn't that hard to manage in the long run?

Rachel: Easing is a measure of a rate of change. For instance, imagine a ball rolling across a table. Now that rate of motion isn't constant. Gravity starts affecting the ball halfway across the table and it starts slowing down, and finally it calls to a stop.

Now the word for that would be ease-out, which is a way of saying it eases out of its motion. It slows down over time. There are many different kinds of easing. There's ease-in where it starts slow and ends fast as kind of an acceleration easing.

There's linear where the rate of motion is constant. It looks very, very mechanical and unnatural to the human eye, because there are no constant rates of change in nature. When it comes to a large team and you have many different motion designers, designers, front-end developers coming in.

Sometimes they might feel like, "Well, this drop down here it needs an easing for when it comes in." I'll just use ease-in, or ease-out, or define my own custom cubic-bezier and use that. A cubic-bezier by the way is a way of defining your own rate of change. It's a formula, a mathematical formula that you can plug into your CSS.

There is the ability for people to really nearly slap all kinds of easing some things and that can be a problem, because easing is also a form of branding, and a physical interface for people.

Now many sites that have a very cohesive animation feel use custom easings for pretty much everything, meaning CSS comes with a set of easings out of a box. But like I said you can define your own. That's why I think it's important in the beginning for somebody to take charge of how that feel that rate change throughout the entire project should feel.

It's good if you are using CSS like using a processor to define a couple of custom easings upfront and say, "You design documentation when you are easing out, and we want you to use variable ease-bounce." If you are changing something so passing, we want you to use ease-fade.

If you are using a Java Script based animation frame port you can define similar functions, and just inform your developers to only use those functions. It will have to become a part of your best practices so people don't just slap in the defaults, but adhere to the ones that have been approved and trained to work with.

Adam: Rachel, the team at DocuSign wanted to know a bit about your thinking on Google's Material Design. In your opinion, have they done a good job at creating an animation framework that can be applied across lots of different interfaces?

Rachel: It's interesting, because when it first came out, it was the first time anybody online had given motion design like an actual page in their documentation in public. It wasn't just a page, but it was many pages that were devoted to this.

For people who don't know Google's Material Design is a skin for the primer project. It's like Twitter Bootstrap. It's got a lot of animation in it. For instance when you move from page to page, it's transitioned. When it first came out everyone was really excited.

It was only a matter of weeks before some people started saying, "Well, I feel the animations are kind of slow," and to be fair that is true. The animations are often tied to page loads. If the page load is slow, the animation probably feels slow too. This can be one of the difficulties with getting your animation timings right.

We talk a bit about that in the seminar, but specifically I think this is the first time we have seen so much energy put into making motion an upfront and center part of a design process. It's one of the best steps I've seen. Material Design spends so many different devices, and so many different used cases that it was no small undertaking to do that.

It was very ambitious and I think they did a great job giving that challenge. Certainly there are things we are going to learn from it as we watch people use, more and more projects made with this product. It's a useful educational experience we are going to gain from.

Adam: Rachel, tell us about what you use for prototyping?

Rachel: My prototyping process is really on glamorous. I've just told you all about these fancy tools that people can use like when I interview people, I know that there are some design teams where they all make movies of how some things should look using after effects, and other people they subscribe to UXPin and InVision.

They have these really nice type prototyping processes, but for me I tend to just send clients wireframes and animatics, or tiny little movies of wireframes and action. Then I tend to work directly with code. I use sublime text. As I'm coding I send users either links to get up pages for the codes and action, or I send them actual videos of, "What do you think if we made it work like this?"

It's small, but that's because I'm a small company out here. If I were working on a much larger project, I would probably insist that we codify that a bit more and start bringing in some of the more formalized products. For now, this suits me just fine.

Adam: Very cool, Rachel, we ask people like you to come to our virtual seminar program for your expertise, and our audience is usually Jones, and they hear a bit more about where they can get more of your thinking, and your great teaching. What do you got for them?

Rachel: I can recommend my newsletter "Web Animation Weekly Enough." I create it every week. I send out fresh links to everything from implementation updates to inspiration for how animation can fit into your workflow. It's the best news in all things animation and motion from across the Web.

You can sign up for it at webanimationweekly.com. If you do something wonderful with animation in the future, we also accept submissions, so please we'd love to see what you're working on.

Also in October, I've got a special announcement. I'm organizing a conference devoted to animation on the Web. It's called "Kinetic." You can learn more about it at kineticpdx.com.

Adam: Rachel, that was great. Thanks for making some more time for us.

Rachel: Thanks for having me, Adam, and thank you, audience.

Adam: To our audience, thanks for your support, and for listening in. Goodbye for now.