Use a skeleton when the forthcoming structure is predictable

What it is

A wait treatment is a selection, not a visual default. When the screen that is about to arrive already has a template — list rows, a profile header, an article column, a fixed card grid — the honest wait language is a skeleton screen, not a spinner. The selection question is whether the system can say, before the payload lands, “matter will occupy these slots”. If it can, fill the wait with that geometry. If it cannot, the next leaf takes over with an indeterminate indicator.

This leaf does not teach how to draw the grey blocks. It states the admission rule: predictable structure is what licenses a skeleton.

Why it happens

During a wait people need two facts: that the system is still working, and what kind of thing is about to own the screen. A spinner answers only the first. A skeleton answers the second, but only if structure knowledge exists independently of this particular response: which page the route maps to, whether permission will remove a whole region, whether rows have a stable height. That knowledge lives in the product’s own templates, not in this network packet.

Predictable is not the same as known content. The title string and the avatar can still be empty; what is known are the slots. Once slots are numbered in the template, vision can partition the screen into “title here, row here” before any bytes arrive. Arrival then becomes objects falling into prepared slots rather than objects bursting out of blankness. A spinner cannot stage that rehearsal, so using one when structure is already known throws the knowledge away and leaves the wait as “a loop is spinning”.

Where it stops holding

Predictability is about this wait, not the whole product. A profile page can be predictable while search results are not; there is no house style that says “we skeleton everything”. When permissions, experiment arms or user-defined modules are revealed only in the payload, the template is a guess and the admission rule fails. Generative output, chat streams and query-shaped result pages change structure with the input. On a wait so short the skeleton never settles, forcing the treatment because “structure is known” creates flicker. A skeleton speaks structure, not remaining quantity; once a wait crosses the attention-holding window and a total is known, progress still has to appear — the skeleton is not a percent-done stand-in.

Applying it

• Keep a selection table by route and template. Pages whose main regions can be sketched with no payload default to a skeleton; pages that cannot should not get one for visual unity.
• Promise only the stable part of this wait: a fixed header, fixed columns, fixed row height. Do not paint modules that appear or vanish with the data just to look busy.
• Do not cover a structure-known list or article with a branded spinner. Leave spinners for actions whose structure is still unknown.
• How to check: with the network off, have someone else mark the major blocks of the loaded screen from the current URL and auth state alone. If they can, a skeleton is licensed; if they cannot, this leaf’s gate is not met.

Related

• Same group: I2.01.2 When structure cannot be predicted, use an indeterminate indicator · I2.01.3 A skeleton that does not match real structure produces a jump · I2.01.4 Skeletons reduce subjective wait estimates more than spinners · I2.01.5 An indicator on a very short load creates needless flicker · I2.01.6 A spinner carries no progress and, used for long, is read as frozen · I2.01.7 Skeleton motion needs one shared cadence; mixed breathing looks cheap
• Nearby: E6.07 Skeleton screens · E6.08 Loading indicators · I2.07 Perceived performance
• Search terms: skeleton screen · predictable structure · wait treatment selection