Design empty loading and unavailable states deliberately

A blank panel does not tell a user whether the business has no records or the application has failed. The same visual space may represent several very different situations. Design those situations alongside the populated screen, with an explicit explanation and a useful action for each. Otherwise the polished demonstration hides the conditions users must handle in daily work.

Distinguish reasons for seeing nothing

Separate a first-use state from a search with no matches. A first-use page can explain the purpose of the area and how an authorized user creates the first record. A filtered result should show the active criteria and offer a way to change them without losing the surrounding task.

Also distinguish lack of permission from lack of data. Do not invite a user to create a replacement record simply because existing records are not visible to that role. Where access is restricted, explain the permitted route without exposing information that the role should not see.

Describe waiting without pretending completion

During an unfinished request, show what the application is trying to obtain. Keep useful existing information visible when possible, but label it if it may be outdated. A loading placeholder should not resemble an actual record or imply that a requested update already succeeded.

WAI identifies waiting, progress, results, and errors as possible status messages when they do not change context.[3] Relevant messages need programmatically determinable roles or properties so assistive technology can present them without receiving focus.[3] Review the announcement behavior as well as the visible panel.

Hypothetical example: a dispatch board

A hypothetical dispatch supervisor opens a route board. On the first day, no routes exist, so the page explains how to create one. Later, a region filter returns no matches and offers to clear that filter. These states share a layout but not an instruction.

If the route service becomes unavailable, the board instead identifies the failed refresh and marks any retained routes as previously loaded. The supervisor can retry or follow the agreed operational fallback. The page must not announce that all deliveries are complete merely because it cannot retrieve them.

Specify transitions and limits

Prepare state examples with the business owner before approving the design. Include the transition from waiting to success, no matches, denied access, or failure. Decide what happens to selection and scroll position when the request eventually finishes.

Extra states increase design and test work, and retained data can become misleading. Choose freshness labels and fallback behavior deliberately. These checks guide product acceptance but do not establish formal accessibility compliance.

• Provide different text for first use and zero search matches.
• Keep active filters visible in the no-matches state.
• Label retained data when a refresh fails.
• Give a real retry, access-request, or creation action where appropriate.
• Test announcements and user location across state transitions.