Our table loaded twenty rows behind a skeleton of three, and the whole page jumped.
When I audited the Scaler platform, I expected the filters to be a mess, and they were. Loading turned out to be worse, though. It was broken in all six modules, and nobody had ever complained about it, because each case felt too small to bother with.
In some modules the content area collapsed to nothing while data loaded, so the page jumped up and then dropped back down when the table arrived. Other modules had a skeleton, which sounds better, except a table of twenty rows would load behind a skeleton of three. It was the same jump, just with better manners.
If you’re an analyst halfway through a compliance report, that jump is exactly how you lose your place. Then you scroll around looking for the row you were on, and the product starts to feel like it’s working against you a little.
We had all the usual loading components in the library. Nobody had written down when to use which one, so people grabbed whatever was quickest to build. I can’t really blame them.
So now I start from the wait itself. If the screen has a predictable layout, like a table or a list of cards, use a skeleton that matches the real thing, with the same row count and the same column widths. For a single action, like a button after you submit, a spinner is fine, delayed by a couple of hundred milliseconds so it doesn’t flash when the response is quick. Anything long and measurable, like an export or an upload, gets a progress bar.
Please don’t let that bar sit at 99%. Everyone has watched a progress bar do that, and nobody has fully trusted one since.
Sometimes the best loading state is none at all. If you like a post or tick off a task, just show it as done and deal with the rare failure. I wouldn’t do that for payments or deleting things, though. When money or someone’s data is involved, a second of visible “working on it” is reassuring, and people actually want it.
The rule we wrote at Scaler was boring: the layout never collapses while something loads. It fixed more than any new component would have.
References