My girlfriend is a huge fan of a K-pop group, and that group is holding a concert in Jakarta at the end of this year. Naturally, she opened the concert site. What greeted her was a different show entirely: almost every element arrived with its own transition, and the page was busy moving before she could read it. To her, none of that motion was necessary. She came to see her idols, not a website.
That moment is why I’m writing this note. Not because the animation was bad. Quite the opposite: it was clearly built with care. But the person in front of the screen never asked to be animated at.
Introduction
There’s one thing people keep getting wrong about those who “hate animation”: they don’t hate all movement.
I once read a LinkedIn post that captured this exactly. The author was fed up with an app that animated nearly every interaction inside it. Yet in the same post, they said there was one animation they genuinely loved: the splash screen when the app first opens.
Those two reactions don’t contradict each other. A logo fading in smoothly while the app gets ready feels natural, because that animation is doing a job: covering a wait that really exists. The animations inside the app weren’t covering anything.
What makes people angry is a landing page where every element floats, or a checkout full of choreography when all they want to do is pay. At that point animation stops helping and starts standing in the way.
So this note isn’t about how to craft beautiful animation. It’s about when animation deserves to exist, and what it means to respect the person on the other side of the screen. In short: it’s about respect.
Animation That Works
Look at the animations people rarely complain about, and you’ll notice they share one trait: they answer a question the user actually has.
A splash screen answers “is this app even running?”. While the logo moves gently on screen, the app is getting ready behind it. Without that animation, you’d be staring at a blank screen, and a blank screen always feels like a broken app.
A skeleton answers “where’s my content?”. Those softly pulsing gray boxes tell you two things at once: the data is on its way, and this is roughly the shape it will arrive in. Compare that with a spinner, which only says “wait” without telling you what you’re waiting for.
A button that shrinks slightly when pressed answers “did my tap register?”. A toast sliding in from the corner answers “what just happened?”, then leaves on its own once its message is delivered.
Notice the pattern. Every animation above works for the user. They’re short, they show up exactly when needed, and they never ask for more attention than the message they carry.
Decorative animation is the opposite: it answers nobody’s question. It asks one instead: “cool, right?”. And it asks that of someone who’s trying to read an article, compare prices, or pay for their stuff.
That doesn’t make decorative animation a sin. Some places exist precisely to impress, like a motion designer’s portfolio. The trouble starts when this kind of animation shows up where people come to get something done.
Animation Has a Price
People’s tolerance for animation isn’t fixed. It drops as their goal gets clearer.
Someone opening a landing page arrives with a question: what is this product, and is it for me? Every element that waits its turn to fade in on scroll delays that answer. Fast scrollers get an even stranger experience: the content seems to chase them, always arriving a beat too late.
At checkout, the goal is as clear as it gets: this person wants to give you money. Their intent is at its highest, and their patience is at its thinnest. Elaborately choreographed step transitions don’t feel premium here. They feel like a checkout line that moves slowly.
That doesn’t mean checkout should be lifeless. Button feedback and clear status changes matter most right here, because the question is at its most urgent: “did my payment go through?”. What has to go is the animation asking “cool, right?”.
Don’t take my word for it. Feel it. The three checkouts below run the exact same flow. The only thing that changes is the motion budget.
The same checkout, three motion budgets
The flow and payment delay stay the same in each mode. Pay in each mode and compare how long the confirmation takes to become readable. If your OS has Reduce Motion on, the most animated mode also calms down.
Motion budget
Your order
- Concert ticket, CAT 8 × 2Rp3.800.000
- Service feeRp80.000
The User Already Told You
So far this has been about taste and patience. For some people, it’s physical.
People with vestibular disorders, opens in a new tab can get dizzy or nauseous from movement on screen. Parallax, elements that scale as you scroll, and transitions that shift the whole page are the most commonly cited triggers. For them, your animation isn’t a minor annoyance. It’s a reason to close the tab while fighting off nausea.
That’s why every operating system ships a Reduce Motion setting in its accessibility menu. Anyone who turns it on has stated their preference politely, in the right place. And the browser forwards that statement to you through a single media query: prefers-reduced-motion, opens in a new tab.
CSS
.toast {
transition:
translate 200ms ease-out,
opacity 150ms ease-out;
}
@media (prefers-reduced-motion: reduce) {
.toast {
transition: opacity 150ms ease-out;
translate: none;
}
}Notice what gets reduced: the movement, not the information. The toast still appears, and its arrival is still visible through opacity. The only thing gone is the positional movement, the kind most likely to trigger dizziness, opens in a new tab. Reduced motion means reduce, not switch everything off until the app feels broken.
WCAG, opens in a new tab covers this in its “Animation from Interactions” criterion: animation triggered by interaction should be disableable unless it’s essential. But to me the reason is simpler than any criterion number: the user already said it. The least you can do is listen.
What prefers-reduced-motion actually changes
The toggle simulates the OS-level Reduce Motion setting. Fire the toast in both modes: the information always arrives, only the movement is dropped.
Simulated OS setting
The CSS the browser applies right now
.toast {
transition:
translate 200ms ease-out,
opacity 150ms ease-out;
}Three Questions
Everything above compresses into three questions. I run through them every time my hands itch to sprinkle transition everywhere.
First, which user question does this animation answer? If there’s no answer, it’s decoration. Decoration only belongs on pages people visit to be impressed.
Second, if I delete this animation, what information is lost? If nothing is lost, the version without it is the better version. Starting small is always possible, and so is adding more later.
Third, what happens when Reduce Motion is on? If you’ve never checked, the answer is probably “nothing changes”, which means someone’s preference is being ignored right now.
Closing
This note isn’t a call to declare war on animation. The right animation is part of the craft that makes an app feel alive.
Once you’re done with the “when” and want to get serious about the “how”, the person to learn from is Emil Kowalski, opens in a new tab. He built sonner, opens in a new tab, the toast library whose behavior I praised earlier, and he teaches at animations.dev, opens in a new tab. His writing is technical and deep, exactly what you want once you’re sure the animation deserves to exist.
Meanwhile, there’s a small experiment you can run tonight: turn on Reduce Motion in your OS, then open a site or app you built yourself. If some information suddenly goes missing, that was an animation doing real work. If what you feel instead is relief, now you know which animations have to go.