Animation is Not a Decoration

We need to hold an intervention for the design community.

Somewhere around the time Framer Motion and Lottie became popular, designers collectively lost their minds. Suddenly, every button press needed a gelatinous bounce, every page load needed a staggered fade-in sequence, and every modal needed to backflip onto the screen.

It looks great on Dribbble. It looks like a Pixar audition tape.

But when I'm trying to check my bank balance at 3% battery while standing in the rain, I don't want to watch your beautiful 800ms transition sequence. I just want to see the number.

Animation in UI is not decoration. It's not there to delight me. It is a functional layer of communication meant to explain changes in state. If your animation doesn't help the user understand what just happened, it's just noise.

Here is the physics of function UI motion.

1. The "Where did that come from?" rule

In the physical world, objects have permanence. If I hand you a cup of tea, it doesn't instantly materialise in your hand; it travels through space from my hand to yours.

In bad UI, things teleport. A user clicks a card, and suddenly a full-screen modal instantly flashes onto the center of the screen. It's jarring. The user's brain had to take a microsecond to reorient itself: "Wait, where am I now?"

Motion must establish origin.

If a card expands into a details view, the new view should grow from the card's position. If a drawer opens, it should slide in from the edge it's attached to. This tells the user, "Hey, that thing you were looking at just got bigger," rather than "Hey, here is a totally new screen we teleported in."

2. Timing is everything

How long should a transition take? Designers love slow, luxurious transitions because they want you to admire their handiwork.

Users hate them. They feel sluggish.

Human perception has thresholds. Anything faster than 100ms feels instant; sometime too instant, like a glitch. Anything slower than 400ms feels like a lag. You are actively wasting the user's time.

The Heuristic:

• Small UI elements : hover states, checkboxes : 100ms - 200ms. Snappy

• Large transitions : page loads, modals opening : 250ms - 300ms. Smooth, but quick.

You aren't making cinema. You're opening a dropdown menu. Chop-chop.

2. Kill the robots

By default, most code uses linear easing for animation. This means the object starts moving at full speed instantly, travels at a constant rate and stops instantly.

Nothing in the real world moves like this except robots and conveyer belts. IT looks cheap and mechanical.

Real objects have mass. They need energy to accelerate and friction to decelerate.

Use physics based easing curves.

• Entering the screen : Ease out : Objects should enter quickly and slow down to park. It feels responsive.

• Exiting the screen : Ease in : Objects should start slow and speed up to escape. They are getting out of your way.

• Never use Bounce unless you are designing a literal game for toddles. Your banking app does not need to be whimsical.

4. The invisible cost

This is where my CS background gets angry.

You designed a beautiful, complex blur-and-scale transition on your Macbook Pro with an M3 chip. It looks buttery smooth.

Now run it on a $200 Android phone. It runs at 12 frames per second, stutters horribly, and drains 5% of the user's battery because you just redrew the entire screen twenty times in half a second.

Not all CSS properties are created equal. Some are cheap for the browser to animate; others are expensive.

• Cheap : GPU handled : transform (translate, scale, rotate) and opacity. Use these 95% of the time. The GPU handles the math easily.

• Expensive : CPU handled : Animating width, height, margin, padding, box-shadow, or blur. These triggers browser reflows and repaints. They force the browser to recalculate the entire layout on every single frame. Avoid animating these if possible.

Motion is a powerful tool for guiding the eye and explaining state changes. But like any powerful tool, it's easy to cut your own foot off with it.

Before adding an animation, ask yourself : "Does this help the user understand the interface better?" If the answer is "No, but it looks sick." Delete it.