Loading State Design

The live example above is plain HTML with Tailwind utility classes, so you can paste it into any Tailwind project. It uses the default type size and spacing p-5 (20px), gap-3 (12px), space-y-2 (8px), mt-5 (20px), constrained by max-w-md and w-10 and w-1/3 and w-1/2 and w-5/6 and w-2/3. Everything sits on a 4px grid, which keeps rhythm consistent when you adapt it.

Colors use Tailwind's neutral stone scale so the pattern stays brand-agnostic. Swap stone-900 for your primary color on the main action, keep body text dark and check contrast after any change.

A finance manager opens a dashboard on a slow hotel connection. Instead of a blank page or a single spinner, she sees the layout immediately: skeleton cards for each metric and grey rows where the table will be. The numbers fill in one card at a time, and nothing jumps around as they appear.

She starts generating a quarterly report. A progress bar and the message 'This usually takes about 20 seconds' appear, and she keeps working on other screens. When the report is ready, a notification lets her know. When one chart fails to load because of the connection, only that chart shows an error with a Retry button, while the rest of the dashboard keeps working.

The team that built the dashboard also tuned the small details: spinners only appear if a request takes longer than about 300ms, so quick actions never flicker, and the shimmer on skeletons is turned off for people who have reduced motion enabled in their operating system. Loading regions are marked as busy, so screen reader users know content is still on its way.

Social and content feeds use skeleton cards that match post layouts, then fill in content progressively.

Dashboards load each widget independently so one slow chart does not block the rest.

AI and generation tools show streaming output or step-by-step progress for tasks that take tens of seconds.

Skeletons should use a neutral tone close to the surface color, with rounded shapes that match the real content dimensions. If you animate them, use a slow, subtle shimmer and disable it with prefers-reduced-motion. Spinners should be small (16 to 24px) and placed where the result will appear. Progress bars need a full, clearly visible track.

On mobile, network conditions vary widely, so show content progressively and avoid blocking the whole screen. Pull-to-refresh is common in feeds, and offline states should tell users what still works.

Set aria-busy="true" on regions that are loading and remove it when done. Delay showing spinners by about 300ms. Size skeletons to match real content to avoid layout shift, and disable shimmer animation when prefers-reduced-motion is set.

In a design system, loading states include skeleton primitives (text line, avatar, card, table row), a spinner, a progress bar and an inline status. Give skeletons the same dimensions as the components they stand in for, and document when to use each indicator so teams do not default to full-page spinners.

Measure real loading times with performance monitoring and track Cumulative Layout Shift. Users tolerate longer waits when progress is visible, so compare satisfaction and drop-off before and after adding better loading states.

Before shipping, run a short usability test with five or so people from your audience. Give them tasks rather than instructions and watch where they hesitate:

For long tasks, explain what is happening and how long it usually takes: 'Generating your report. This usually takes about 20 seconds.' Avoid vague or jokey messages that repeat forever. For background saves, short status text like 'Saving...' and 'Saved' is enough.

If you use an AI UI generator such as Inspo AI, these prompts are a good starting point for exploring variations of this pattern:

Loading states connect to error messages when something fails, file upload progress, and toast notifications when background work finishes.