INTERFACE DESIGN
The screen should say what the system knows
Design loading, empty, error, and success states that give people accurate information and a useful next action.
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.