Axiom

Motion & interaction

Stagger without blocking

Stagger grouped entrances only when it improves rhythm, and keep delays short so interaction is never blocked.

TagsStaggerTiming
Do

60ms steps — last row lands at 340ms

Don't

220ms steps — last row lands at 660ms

Play both, then read where the last row lands — stagger that delays reading is a bug
Do

30-80ms between items

Don't

220ms between items

How to apply it

  1. 1

    Set stagger delay between 30ms and 80ms per item, never open-ended cascades.

  2. 2

    Cap total stagger duration so the last item is interactive well under a second.

  3. 3

    Only stagger grouped entrances where the rhythm actually reads as related, not every list.

  4. 4

    Allow pointer and keyboard interaction on already-revealed items before the stagger finishes.

Why it works

Staggered entrances help users chunk a group of items as one related unit arriving together, a known cognitive benefit of sequential reveal. But that benefit only holds if delays stay in the 30-80ms range per item; push much beyond that and the stagger becomes a cascade the user has to sit through before anything is usable. Short per-item delays keep the rhythm perceptible without blocking interaction.

What breaks

A list of ten items staggers in at 200ms per item, the user tries to click the fifth item while it is still animating, and the interface reads as sluggish and unresponsive for over a second.

Review questions

  1. 1

    Is the delay between staggered items within roughly 30-80ms rather than a long cascade?

  2. 2

    Can the user interact with earlier items while later ones are still animating in?

  3. 3

    Does the stagger actually improve the sense of a related group, not just delay the UI?

Related rules