I2.11.3too-fast cadence looks completedesign

A presentation cadence that is too fast makes people think the content is complete and miss what still arrives

Aliases: false completion · missed late chunk · premature completeness

What it is

The main column lands and the page looks finished: readable, tappable, scroll already seems to hit the bottom. Seconds later comments, related items, a legal footnote insert. People have already coded “complete” and started the next move; later chunks knock after the model has closed. Too-fast cadence is not the clock being short. It is “looks complete” arriving far earlier than “actually complete”, so later parts are treated as never having existed.

Why it happens

A sense of completeness comes from several cues holding at once: no wait chrome, the main-task region filled, the scrollbar looking like the end, no obvious holes. If chunking grants all of those cues on the first chunk, completeness fires early. Once people start the next move (share, order, close the page), attention stops monitoring “is another chunk coming”. Later content, even if it does not shove layout, has missed the window in which it would have been read — a fee in a footnote, a late stock warning, a late “3 more results”.

Cadence is not the same as importance order. Painting the main column first is right; the error is the main column also completing the completeness cues, with no mark that more is coming. Too fast is too-fast cues, not too-fast bytes.

Where it stops holding

Late chunks that do not affect the current task (footer social icons) can be missed; completeness need not be held for them. Safety, money, legal, stock — late arrivals that would change a decision already made — cannot lean on “people should wait a bit longer”. Either they enter the first chunk, or completeness must not form before they arrive. People who refresh or scroll to a reserved slot are still monitoring; the too-fast misread does not happen to them. Extremely slow follow-up chunks (recommendations tens of seconds later) will be gone from even if marked “more coming”; those belong in a notify-after-leave or next-visit path, not on the hope that someone is still on the page.

Applying it

  • While a task-relevant chunk has not arrived, keep one incompleteness cue: a bottom slot, a light “comments still loading”, a scrollbar that is not yet at the true end.
  • Information that would change a decision must not live in a chunk after “looks complete”. Bind it into the first glance or the main column.
  • When a late chunk arrives and the person is still on the page, use a local hint, not a whole-page flash, to open one corner of a model that had closed.
  • How to check: record a session that orders or shares after seeing only the main column, then release the footnote and stock. If the critical sentence never entered gaze or the decision, cadence was too fast — pull that sentence forward, or do not draw the page as already-at-bottom during the main-column phase.

Related

  • Same group: I2.11.1 Progressive rendering must reserve space for chunks that have not arrived, or the layout will shift · I2.11.2 People may act before every chunk has arrived; those early actions have to be handled · I2.11.4 Every step of chunked presentation should be a coherent usable state, not a half-built product
  • Nearby: I2.03 Chunked loading · I2.07 Perceived performance · I1.03 Attention-holding ceiling
  • Search terms: false completion · missed late chunk · premature completeness

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/I2.11.3