Motion is the only part of an interface that costs the user time whether they wanted it or not. That is why we treat it as an argument that has to be won per animation, rather than as a finish applied at the end.
Three questions worth animating#
- Where did this come from?
A panel that grows out of the button that opened it needs no explanation. The same panel appearing in the middle of the screen needs a sentence.
- How long will this take?
Progress is motion's best use. A determinate bar beats a spinner every time, because a spinner only says “alive”, not “nearly there”.
- Did it hear me?
Sub-100ms feedback on press. Not decoration — the difference between an app that feels broken on a slow connection and one that feels merely slow.
Anything that answers none of the three is decoration, and decoration in an interface is a cost you charge every single user, every single time, for something they will notice exactly once.
Durations we actually use#
| What | Duration | Curve |
|---|---|---|
| Press feedback, hover | 80–150ms | ease-out |
| Something entering | 200–320ms | cubic-bezier(.2,.6,.2,1) |
| Something leaving | 120–200ms | ease-in |
| Layout settling | 300–400ms | spring-ish, one overshoot |
Reduced motion is not a downgrade#
prefers-reduced-motion is a real preference from real people, some of whom get physically ill from parallax. The correct response is not a slower version of the same animation — it is the same information, delivered without movement.
@media (prefers-reduced-motion:reduce){
/* the card no longer lifts — the border still tells you it is hovered */
.bl-card:hover .bh-field{transform:none}
.bl-tetro{animation:none}
}Which is a good test of whether the animation was carrying meaning in the first place: if switching it off loses information, the information should not have been in the animation alone.