Dashboard UX Lab

Scenario 2 of 6

Loading

A two-second response: long enough to notice, short enough to wait.

Try it in the lab

Expected behaviour

For the first 300ms nothing changes. Then skeletons hold the shape of each widget until the data arrives.

Why it behaves this way

Most responses finish quickly. Delaying the skeleton avoids a flash of placeholder content on fast requests while still giving feedback on slower ones.

  • Delay skeletons by about 300ms. Under that, a placeholder reads as a glitch rather than as progress.
  • Skeletons should mirror the real layout (card count, chart height, table rows), not a generic shimmer block.
  • Mark the updating region with aria-busy and announce the loading state once, politely.

Accessibility

“Loading dashboard data” is announced once, and the region carries aria-busy so screen readers do not read half-rendered content.

Mistakes this scenario exposes

  • A full-page spinner that hides content the user could already read.
  • Announcing “loading” repeatedly on every re-render.