Loading, empty, error, and success UI states

A loading indicator makes a claim: work is underway. An empty screen makes another: there is nothing to show. Treat those claims as part of product behavior. Before drawing visual variants, write down what the application actually knows and which event changes that knowledge. This exposes awkward cases, such as an accepted request whose final result is still unknown.

Make waiting specific

Name the operation beside the indicator: “Loading projects” or “Preparing export.” If existing information remains useful, keep it visible and explain that it is being refreshed. Replace it only when the new result is ready or when showing it would be misleading.

Use measured progress when the system has a meaningful total. Otherwise, communicate activity without an invented percentage. Disable controls that would create conflicting work, while keeping unrelated navigation available where possible. A waiting state should also have a planned exit when work cannot finish.

Explain why the page is empty

An account with no projects, a filter with no matches, and a failed request need different responses. The first can offer creation. The second can offer a way to clear filters. The third needs an explanation and recovery.

Write the message around the cause you have established. If the application cannot determine whether records exist, “No projects yet” is an unsupported claim. Check that the proposed action addresses the cause: creating another record will not fix a filter that excludes it.

Make errors useful

Describe what could not be completed and what the person can do next. Keep valid input available so that correcting one field does not require starting over. Place a specific field problem near that field; keep an operation-wide failure near the action it affects.

Distinguish a confirmed rejection from an unknown outcome. “The title is required” supports an immediate correction. “We could not confirm whether the export finished” requires a way to check its status. Do not offer a retry that could repeat important work without considering how the operation handles another submission.

Earn the success message

Tie success to the outcome the interface promised. If the action means “Create export,” receiving the request is only one step. HTTP 202 indicates acceptance for processing, not completed processing, and the eventual work can still fail. A product using that response should communicate the pending state and provide a way to discover the final outcome. MDN: 202 Accepted

Once completion is established, say what changed and make the result reachable. A persistent link to the created item is often more useful than a brief celebratory message that disappears before someone can act.

Make the information available to everyone

When status text changes without moving focus, expose its meaning through suitable roles or properties so assistive technology can announce it. W3C's guidance covers waiting, results, progress, and errors. It also cautions against excessive announcements. A routine update should not repeatedly interrupt someone working elsewhere. W3C: Status Messages

Review the whole sequence with a slow response, an empty result, a rejected input, and an uncertain outcome. For each transition, ask whether the message describes known facts, whether existing work survives, and whether the next action is clear. Those answers matter more than whether every state uses the same illustration.

Practice recording an uncertain state

Use the release review tool to practice recording an unresolved interface claim. Start a blank review with release “state-card-01 — fictional exercise,” environment “Fictional worksheet exercise,” and browser “No browser behavior is being tested.” Leave every check unreviewed except check 07, “See loading and empty states.”

Set check 07 to “Needs follow-up” and leave its evidence field empty. The expected summary is one follow-up and seventeen unchecked items. The tool should also flag one reviewed check without evidence or a reason. That warning tells you that the record needs an explanation; it does not diagnose the interface itself.

Now enter this invented note: “Fictional example: the screen says ‘No saved patterns yet’ while completion is unknown. The record count has not been checked.” The missing-evidence count should fall to zero while the follow-up count remains one. Writing a note completes the record's explanation; it does not resolve the uncertainty described in it.

Export JSON and locate check 07. Its status should remain “followup,” its note should remain intact, and the export should contain all eighteen checks. If a report instead counts this exercise as an observed pass, its conclusion overstates the supplied evidence. Keep the remaining checks marked unchecked.

For an actual review, replace the invented note with the fixture, message, known request outcome and next action you observed. Confirm the empty result before accepting wording that says there are no records. Retain the unresolved outcome if the available evidence cannot establish that fact.

The interface-state evidence study applies the same boundary to twelve controlled browser fixtures. Its screenshots and downloadable observations show the exact message, role, action, focus target, and unresolved fact recorded at desktop and narrow viewports.

Continue with Release review tool.