· 8 min read

Motion that survives a second look

The test of an animation is not whether it impresses once. It is whether it still feels right the fortieth time, which is a different problem entirely.

The test of an animation is not whether it looks good the first time. It is whether it still feels right the fortieth time, and those are almost opposite problems.

The first time, a person is watching the animation. By the fortieth they are trying to get somewhere, and the same movement that read as craft now reads as a wait. Almost every piece of motion I have had to remove was removed for that reason, and almost every one of them was approved in a review where everybody saw it exactly once.

Motion is an answer to a question the interface raised

The useful frame is not "should this be animated". It is "did something just happen that a person needs explaining".

When a panel appears from nowhere, there is a real question in the room: where did that come from, and is the thing I was reading still there behind it. Motion answers that by showing the relationship. The panel slides up from the button that summoned it, so the connection between the two is stated rather than assumed, and when it leaves it goes back where it came from.

That is the whole job. An element that fades in over 400ms because fading is nice is not answering anything. It is a delay with a gradient on it.

The practical version of this test: if you can describe what the animation tells the user in one sentence that does not contain the word "polish", keep it. If you cannot, it is decoration, and decoration is the thing that stops being charming on the fortieth viewing.

The decisions, in the order that matters

Motion work goes wrong when the interesting decisions are made first. The order that has held up for me runs from the cheapest question to the most expensive one.

Should it move at all. Most things should not. A list that reorders itself, a value that changes, a panel that opens: those raised a question. A button that already tells you what it does when you look at it did not.

What property moves. This is decided before the curve and before the duration, because it decides whether the animation costs anything. transform and opacity are composited and effectively free. width, height, top and left are not: they invalidate layout on every frame, and on a mid-range phone that is the difference between motion and stutter. The number of animations I have seen fixed by changing nothing but the property is high enough that I now check it first.

Which curve. Then, and only then, how long.

Doing it in this order means the two questions people enjoy arguing about come last, when most of the candidates have already been eliminated.

Durations, and why the numbers are smaller than they feel

Designing an animation means watching it a hundred times, and a hundred viewings make everything feel too fast. This is the single most reliable source of slow interfaces: the person who chose the duration was the person least able to judge it.

The ranges that have survived contact with real products, for me:

Something small changing state, a hover, a toggle, a colour: 100 to 150ms. Below about 80ms it stops reading as motion and starts reading as a flicker, which is worse than an instant change.

Something appearing or leaving, a menu, a tooltip, a popover: 150 to 250ms.

Something large moving across the screen, a sheet, a full-screen transition: 250 to 400ms, and 400 is already generous.

Anything above roughly 400ms needs a reason that is not aesthetic. It is a wait, and the person is now waiting on your taste.

The correction for the hundred-viewings problem is to leave it overnight and come back. Almost every duration I have set has come down the next morning, and none has ever gone up.

Curves say who is in charge

Two easings cover nearly everything, and the choice between them is not a matter of feel.

Something entering should ease out: fast at the start, settling at the end. It arrives immediately, which is what a person asked for, and decelerates into place, which is what makes it feel like an object rather than a repaint.

Something leaving should ease in: slow at the start, accelerating away. The element hesitates for a moment, so the eye can confirm what is going, then goes quickly, because nobody is waiting to look at something that is disappearing.

ease-in-out is the default in a lot of tools and is the right answer for something moving from one place to another while staying on screen. It is the wrong answer for entering and leaving, and it is the reason a lot of menus feel slightly reluctant.

Springs are worth having, but for a narrower set of cases than their popularity suggests: something a person dragged, threw or is otherwise physically manipulating. A dropdown that bounces is telling a story about mass and momentum that nothing in the interaction supports.

Interruption is the actual test

Here is where most motion work is still unfinished when it ships. Every animation looks correct when it runs from start to finish in an empty room. What decides whether it feels good is what happens when someone does the next thing before it has finished, and people do that constantly.

Open a menu and close it halfway through the opening. Does it reverse from where it is, or does it snap to fully open and then play the close from the top? The second one is what you get for free, and it is the reason an interface can feel expensive on the first click and cheap on the third.

A hover that has an enter transition and no exit transition. Move the pointer across a row of six cards quickly and you get six things easing in and six things vanishing. It looks like a fault, and technically it is one.

A list that animates on reorder, given two reorders in quick succession. Either the second one interrupts cleanly or you get elements travelling to positions that no longer exist.

The rule I have ended up with: an animation is not finished until you have tried to interrupt it. Not as a QA step, as part of building it, because the fix is usually structural rather than cosmetic and it is much cheaper before the thing is done.

Motion belongs in the tokens

Durations and easings stay magic numbers far longer than colours do, and the effect is quieter and harder to diagnose. A product where one thing settles over 200ms and the next over 320ms feels subtly unwell, and nobody in the review can say why, because no single screen is wrong.

Two or three durations and two easings are enough for almost everything, named for what they are for rather than what they measure. Something appearing, something moving, something leaving. Once those exist, "make the whole product feel a bit snappier" is one edit rather than a search through every transition in the codebase, which is the same argument that makes a token system survive a rebrand.

It is worth making this one enforceable. A raw 0.28s in a stylesheet is not a crime the way a hardcoded hex is, so it does not get caught in review, and that is exactly why it accumulates. A lint rule that only accepts the motion tokens costs an afternoon and settles the question permanently.

Reduced motion is a preference, not a switch to turn things off

prefers-reduced-motion is usually implemented as "disable all animation", which is both the easy reading and the wrong one. The preference exists because vestibular disorders are triggered by large movement and parallax, not because some people dislike transitions.

Stripping motion entirely takes away the thing the motion was doing. A panel that appeared with no transition at all still raises the question of where it came from, and now nothing answers it.

The better response is to keep the meaning and drop the movement: replace a slide with a fast cross-fade, cut the distance travelled, remove parallax and anything that scales significantly. The relationship survives, the trigger does not. It also has a pleasant side effect, in that it forces you to articulate what each animation was actually communicating, and the ones where you cannot answer are the ones to delete for everybody.

What is left when the flourishes go

The motion I am still happy with years later is nearly invisible. A menu that comes from its button. A row that settles rather than snaps when it moves. A value that counts rather than jumps, so the eye registers that it changed. None of it would survive being described in a portfolio.

The stuff that got cut was, without exception, the stuff that was fun to build. Staggered entrances on a list that people scroll past twenty times a day. A page transition that added 300ms to every navigation for a wipe nobody looked at after the first week.

The useful question at the end of a motion pass is not whether it feels premium. It is whether someone using this all day would notice its absence. If the answer is that they would just get there slightly sooner, you have found what to remove.