Motion Is a Feature, Not a Garnish

Motion is usually the last thing added and the first thing cut. It gets framed as delight, polish, a bit of juice — seasoning you sprinkle on once the real work is done. I want to argue the opposite: good motion isn't decoration, it's information, and cutting it removes meaning rather than shine.

Motion is continuity

When a panel appears from nowhere, the user's brain does a small, unpaid job: figure out where this came from and how it relates to what was on screen a moment ago. When that same panel grows out of the button they tapped, the job is done for them. The animation isn't prettier — it's answering a question the static version left open.

This is why the same 300ms can feel expensive in one product and invisible in another. Motion that expresses a real spatial relationship reads as the interface being coherent. Motion applied to an element that came from nowhere and means nothing reads as latency with a bow on it.

Give motion a budget

Features get requirements, owners and a definition of done. Motion usually gets a vibe and whatever time is left. So I give it a budget, written down before anything is animated: which two or three transitions in this flow carry meaning, how long each is allowed to take, and what happens if the device can't afford it.

The budget is the thing that makes cutting easy later. If a transition isn't on the list, it doesn't get built — and when the page feels slow, you're deleting animations by evidence rather than by opinion. It also forces the useful conversation early: is this motion explaining something, or is it covering an eight-hundred-millisecond fetch we should just fix?

The rules I actually keep

1. Motion should explain, not entertain. If an animation isn't clarifying a spatial or causal relationship, it's noise wearing a nice easing curve.
2. Enter slow, exit fast. Things arriving deserve a moment; things leaving should get out of the way. Roughly 300ms in, 150ms out.
3. Ease out, almost always. Linear motion feels mechanical because nothing in the physical world moves that way. Nature decelerates, and so should your interfaces.
4. Interruptible beats correct. A user who changes their mind mid-animation should never wait for it to finish. Springs that can be redirected beat rigid timelines every time.
5. Animate the cheap properties. Transform and opacity are nearly free; width, height, filter and box-shadow are not. When you do animate an expensive one, know why and measure it.

Easing is a vocabulary

Most motion that feels wrong isn't badly timed, it's badly phrased. Easing is the grammar of the thing, and there are only about four sentences worth learning:

• Ease-out for anything arriving. Fast start, soft landing. This is the default and it is the correct answer maybe 70% of the time.
• Ease-in only for things leaving the screen entirely. Anywhere else it reads as hesitation.
• Springs for anything the user is directly manipulating — dragging, expanding, dismissing. A spring can be interrupted and redirected mid-flight, which matters far more than the overshoot everyone notices first.
• Linear for continuous, non-narrative motion only: progress rings, marquees, loading shimmers. Anything that represents a state changing should never be linear.

Durations follow from the distance travelled, not from a house style. Something moving 40px has no business taking 400ms. My working set is 120–180ms for small state changes, 240–320ms for a panel or a page region, and a spring — not a duration — for anything the user's finger is on.

A worked example: the index at the bottom of this page

There's a small capsule parked at the foot of this essay. Closed, it's a progress ring, the word Index, and a percentage. Tap it and it becomes a panel listing every section, with the one you're currently in marked. It's a good example because it would have been so easy to build as a menu — and a menu would have been worse in a way most people wouldn't be able to name.

Three decisions, each of them motion decisions:

• The capsule grows; nothing is replaced. The row you tapped is still there when the panel opens — it slides into the corner of the surface that grew underneath it. Because the object persists, you never have to re-find your place. A modal that fades in over the top would have cost you that, silently.
• The list develops out of a blur rather than sliding in. Blur-to-sharp reads as this was always here, coming into focus, which is exactly the relationship a table of contents has to an article. A slide would have implied the list came from somewhere else.
• Scrolling closes it. Motion is only half of an interaction; knowing when to leave is the other half. If you've scrolled, you've moved on, and the index shouldn't need dismissing.

The whole thing is a spring on width and height, a couple of translated children, and one animated blur. Perhaps forty lines of real motion code. It is the single most-touched element in the reading experience, which is a good ratio, and a reminder that the impact of motion has almost nothing to do with the amount of it.

Debugging motion that feels wrong

"It feels off" is the least actionable sentence in design review, and it's the one you'll hear most. Motion is fast enough that the eye registers the problem and the brain can't name it. So I go through the same four checks, in order, and it's almost always one of them:

1. Slow it down 8×. Nearly every problem is visible at 12.5% speed and invisible at full speed. Chrome's animation panel does this in one click; do it before you change a single value.
2. Check the distance. Nine times out of ten a transition feels sluggish because the duration was copied from something that travelled four times as far. Duration follows distance.
3. Check what else is moving. Two elements animating on different curves at the same time reads as broken, not as rich. Either they share a curve or one of them waits.
4. Try to interrupt it. Click, then immediately click again. If the second input queues behind the first animation instead of redirecting it, that's your problem — and it's a state-management bug wearing a motion costume.

The fifth check, when none of those land: delete the animation entirely and see whether anyone notices. Roughly half the time, nobody does, and you've just found something that was only ever costing you.

The discipline is restraint

The failure mode isn't too little motion — it's too much, applied evenly. When everything animates, nothing is emphasised, and the interface starts to feel like wading through syrup. The skill is choosing the two or three transitions that carry meaning and making the rest instant.

A useful test: turn every animation off and use the product for ten minutes. The places where you get momentarily lost are where motion was doing real work — animate those. Everywhere else you didn't miss it, and that's your answer.

Reduced motion is a contract

Respect the people who don't want it. prefers-reduced-motion isn't an edge case to handle grudgingly — it's a promise that your motion was always optional meaning, never load-bearing meaning. If the product breaks without animation, the animation was hiding a design problem.

Honouring it well is more than setting durations to zero. Cross-fades instead of slides, instant state changes instead of springs, and — crucially — the same information still visible. The index on this page still opens, still marks your section, still shows the percentage. It just stops moving. That's the contract: nothing is lost except the motion itself.

If your interface stops making sense with motion turned off, the motion was covering for the design.

Treat motion like a feature. Give it requirements, give it a budget, and cut the parts that don't earn their keep. The result reads as premium — but premium was never the goal. Clarity was.