UX-Animation – die Grundregeln

Good UX animations feel natural, subtle, and unobtrusive. They almost feel like the product is physical and responding to what the user is doing, not like a cartoon that’s been tacked on top. A big part of that is keeping them quick, keeping the motions subtle, and making sure they have a real purpose for being there. First off, they should be very quick. UX animations should be between 100 milliseconds and 500 milliseconds.

And that’s at an absolute maximum! Most of the time you don’t want them above 300 milliseconds or so. That’s really fast! It’s 1/10th to 1/2 of a second, which is much faster than most designers expect. And it might look rushed when you’re designing it and watching it over and over.

Lag time for longer animations

But remember, the longer animation is, the more lag time the user experiences. That becomes really frustrating. Especially on the second, third, or fourth time that you see it. You want the interface to feel snappy and responsive.

The general rule for timing is: the further something has to move on the screen and the more complex the animation, the more time you’re gonna need for it to look natural.

That means you should avoid big exaggerated movements especially on the desktop, where you have a lot more ground to cover. More complex animations take more time and they tend to be more distracting so, keep the transitions simple. Icons don’t need to dazzle users with a dance routine. A simple color changer halo appearing is enough to signal that something’s been clicked.

Avoid things bouncing back and forth and stretching like they’re made of rubber.

D. Laseur – Founder Flatline Agency

You take the physical metaphor too literally, it feels cartoonish and woozy. You also want to use easing to make the timing feel natural. You want things to accelerate slightly when they first start moving and slow down a little bit before they come to rest. Things in the natural world don’t move at a perfectly linear rate. They speed up and down a little bit.

So this box is moving linearly.

It looks stilted and awkward

This one has a bit of easing applied at the beginning and the end. Doesn’t it look better? So a small amount of easing makes things move more naturally and it helps the user’s eye track where something is moving.

Finally, animations need to serve a purpose and they need to communicate something to users. Don’t just include them to try and delight or communicate personality. That gets old quickly. They’re most useful for three reasons, feedback, discoverability, and transitions.

When used for feedback, keep it subtle

Basic principles – UX design

Clicking the cart doesn’t need to show a product thumbnail image, or swing in a big arc across the screen into the shopping cart. Simple color changes on the button and a little indicator on the cart are plenty to confirm that the system understood the user’s click. While you can use animation to draw attention to things that would otherwise be overlooked, don’t use animation to make up for weak signifiers.

The error notification

Showing an error notification sliding into view can be good because it helps users to notice it. Having a dancing arrow icon on a page that has a false floor is bad!

Just make the page look scrollable instead. Animations can also help with transitions because they can provide a visual metaphor for what’s happening. This goes beyond just a fancy loading indicator.

You can use them to help communicate the type of transition that’s happening. On the app store here when you click on an app card, it quickly morphs into a full-screen overlay.

That helps to communicate that you’re looking at the same thing, just in more detail. If that window just appeared instantly, it wouldn’t be the end of the world but the transition helps communicate the relationship between that full-screen view and the card on the previous screen. It also subtly suggests that you can swipe to close it. That can help the user unconsciously build their mental model of how the system works.

Interactions like that morphing card usually can’t be configured in a page builder and need to be hand-coded, which is exactly the kind of implementation work our custom development team handles.