Skip to content
Noa Lindqvist
Writing

Motion with a job

4 min read

Most interfaces have too much motion and not enough of it doing anything. A card slides in, a button bounces, a number counts up from zero, and the person using it learns nothing they didn't already know.

The test I use is simple. Before I add an animation, I write down the one question it answers for the person watching.

Questions worth answering

  • Where did that come from? A menu that grows out of the button you pressed tells you what opened it.
  • Where did it go? An item that shrinks toward the trash tells you where to find it again.
  • Did it work? A check that draws itself after a save is a receipt.
  • Is something happening? A slow pulse while a request is out means you don't press the button twice.

If I can't fill in the blank, the animation goes.

Speed is part of the answer

Motion that explains still has to get out of the way. Anything someone sees a hundred times a day should take well under a quarter of a second, and anything triggered from the keyboard should usually not animate at all.

The more often something happens, the less animation it can afford.

A good default for things entering the screen is a short ease out, so the movement starts fast and settles gently.

.menu {
  transition: opacity 180ms cubic-bezier(0.23, 1, 0.32, 1),
    transform 180ms cubic-bezier(0.23, 1, 0.32, 1);
}

And respect people who asked for less. Under prefers-reduced-motion, show the final state straight away rather than a slower version of the same thing.

Enjoyed it? Let me know.