· 3 min read
How long should a stagger be?
Everyone reaches for a stagger and nobody says how to pick one. Three values that cover almost everything, the arithmetic that decides whether a list is charming or tedious, and why the per-item number is the wrong thing to tune.
Staggering is the first thing anyone does to a list. Four cards appear, they appear one after another instead of all at once, and it immediately looks more considered than it did.
Then you pick a number. Usually 100ms, because it was in the example you copied. And it works, until the list has twelve items in it and the last one shows up nearly a second and a half after the first, and nobody can say why the page now feels slow.
The per-item delay is the number everyone tunes. It's the wrong one.
The arithmetic nobody writes down
A staggered entrance takes:
total = stagger × (count − 1) + durationThat's it. But it's worth writing out because the term that grows is the one you didn't choose. The stagger is a number you picked once; the count is whatever the data happens to contain.
At a 100ms stagger with a 220ms entrance:
| Items | Total |
|---|---|
| 3 | 420ms |
| 5 | 620ms |
| 8 | 920ms |
| 12 | 1,320ms |
| 20 | 2,120ms |
Three items is crisp. Twelve is a second and a third of watching a page assemble itself, during which the reader cannot do anything. Twenty is a loading screen you built on purpose.
Nothing went wrong between three and twenty. The stagger is identical. The list got longer, and the animation got longer with it, and no one was watching the total.
Three values cover almost everything
verve's motion system carries three, and the names are the decisions:
| Delay | What it reads as | |
|---|---|---|
| tight | 60ms | One gesture with texture. You see a ripple, not items. |
| base | 100ms | Individually legible, still one movement. The default. |
| loose | 160ms | Deliberately sequential — a list introducing itself. |
Under about 50ms a stagger stops being perceptible as sequence and just softens the edge of a single event. Over about 200ms the items stop belonging to each other and start being separate arrivals, which is occasionally what you want and usually not.
So the useful range is narrow. That's the good news, and it's why tuning the per-item delay feels unproductive: you're adjusting the one term that barely matters.
Budget the total, then derive the stagger
Decide what the whole entrance is allowed to take, and let the stagger fall out of it.
A reasonable ceiling for a list arriving on screen is about 500ms. Past that you're asking someone to wait for content they can already see. Rearranged:
stagger = (budget − duration) ÷ (count − 1)With a 500ms budget and a 220ms entrance: five items gives you 70ms, eight gives 40ms, twelve gives 25ms. Below about 50ms the sequence stops reading, which is the signal that you've left the range where staggering helps at all.
That's not a failure. It's the arithmetic telling you something true: a long list shouldn't be staggered item by item.
What to do with long lists instead
Stagger what's on screen and nothing else. Twenty rows where only six are visible means six staggered arrivals and fourteen that are simply already there when the reader scrolls to them. Nobody watched the other fourteen arrive, so nothing is lost.
Or stagger groups, not items. Three sections of six, staggered at the section level, reads as structure. Eighteen individually delayed rows reads as a progress bar.
Or cap the total and accept the overlap. A 25ms stagger across twelve items is not a sequence any more, but it does soften the moment where everything appears at once — which is the actual job most of the time.
Two places the number should change
Exits are not entrances played backwards. Leaving isn't a performance: the reader has already decided, and making them watch a considered farewell feels like the interface is arguing. An exit wants the next stiffer spring, less travel, and usually no stagger at all. The thing you dismissed should be gone.
Reduced motion removes the stagger entirely. A stagger is choreography expressed as delay, and delay is what a reader who asked for less movement is trying to avoid. Under prefers-reduced-motion everything that survives — the fades — starts at once and finishes inside about 150ms. Which is worth noticing: if your entrance is only a stagger, then under reduced motion it's nothing at all. That's usually the right answer, and it's worth knowing it's the answer you've chosen.
The actual rule
Pick the total first. 500ms for a list arriving, less if it's a menu you just opened, more only if the sequence itself is the content.
Then take the stagger the arithmetic gives you. If it's under 50ms, stop staggering items and stagger groups instead.
The number that matters is the one nobody puts in the code.