On this page
An empty list can mean that the account has no records, the current filter matches nothing, the user lacks access, or the request failed. Showing the same cheerful illustration for all four conditions hides information the user needs to continue.
Start by naming the state in the product's behavior. Then choose the message and action. Copy cannot repair an application that reports a failed request as a successful empty result, so design and implementation need the same state definitions.
Distinguish absence from failure
A successful request returning no records is evidence of absence within the requested scope. A failed request provides no reliable answer about whether records exist. Those outcomes should remain distinct in the data layer and the interface.
For example, “You have not created a project yet” is appropriate only when the application knows that is true for the current account. If the service is unavailable, use a failure message and preserve the user's context. Do not invite them to create another project because the existing ones failed to load.
This distinction belongs in the acceptance criteria, including what happens after refresh, retry, account switching, and a slow response.
Give first use one meaningful action
A first-use state can explain what the area is for and provide the next action the user is allowed to take. Keep the explanation connected to the task: create a project, add a saved address, or invite a collaborator.
Avoid placing several equally prominent setup actions on a blank screen unless the user needs to choose between them. A short example can clarify the expected result, but sample data must be clearly identified so it is not mistaken for the user's own records.
If the user cannot create the first record because of permissions or an unfinished prerequisite, explain the real dependency. A disabled button without context turns a friendly welcome into a dead end.
Keep zero-result searches tied to the query
Show the search term or active filters that produced the empty result. Offer a relevant way to adjust them, such as clearing a selected filter or revising the query. Preserve what the user entered so they can understand the comparison.
Do not silently broaden a search and present unrelated records as if they matched. If the product offers suggestions, label them clearly and keep them separate from actual results.
Check the empty state after pagination too. A changed filter may make the previous page number invalid. Resetting or correcting the page deliberately is better than showing “no records” while matching items exist on page one.
Handle access limits without leaking information
An account may have no permission to view a record or section. The interface should explain the permitted next step without revealing information the user is not authorized to know. The appropriate wording depends on the product's security model.
Coordinate with the authorization behavior rather than inferring access from an empty array. The server should enforce access; a hidden button is not an access control. If the product supports requesting access, explain who receives the request and what information is shared.
For a shared device, verify that an account switch does not leave the previous user's empty-state suggestion, record title, or draft visible. The state belongs to the active account and scope.
Make service failures recoverable
If loading fails, state what could not be completed and provide a useful next action. A retry can be appropriate when it repeats a read safely. Preserve filters, drafts, and location so the user does not have to reconstruct the task.
Avoid blaming the user's input when the service is at fault. GOV.UK's design guidance distinguishes user-correctable errors from service problems. That principle helps keep the action relevant: correcting a field is different from waiting or trying the request again.
If the product has a known alternative route, provide it with accurate availability. Do not promise that support is online or that data is safe unless the system and operating process support the statement.
Write state-specific copy as a small table
The following examples are illustrative product copy, not universal wording.
| Verified state | Explanation | Relevant action |
|---|---|---|
| New account with no projects | “Create your first project to organize the work.” | Create project |
| Search completed with no matches | “No projects match these filters.” | Clear or change filters |
| Current role cannot use the area | “Your role does not include this section.” | Follow the approved access route |
| Request failed | “We could not load your projects.” | Retry the read or use a documented alternative |
| Previously saved view is stale | “This view has changed since it was saved.” | Review the current scope |
Use words that fit the actual product. The table is valuable because it forces the team to connect evidence, message, and action.
Make changes perceivable without disrupting the task
When results change dynamically, ensure that status information is available to assistive technology. W3C guidance on status messages addresses communicating such changes without requiring an unnecessary focus move.
Keep keyboard focus predictable. A filter returning no results should not unexpectedly move the user to the top of the page or hide the control they were using. Check the order and labels of any new action presented in the empty state.
Do not rely only on color, an illustration, or animation to explain the condition. The text and controls should communicate the same meaning when images are unavailable or motion is reduced.
Test the state transitions, not only the screenshot
Review first use, successful results, zero matches, permission changes, slow loading, failure, and retry. Include a late response from a previous query so stale data does not replace the current state.
Observe users attempting the actual task through a prototype or working build. The user-testing guide helps distinguish a visually attractive screen from one people understand. Ask what they think happened and what they would do next.
An effective empty state answers those questions accurately. It remains part of the workflow, with the same attention to data, access, and recovery as the populated screen.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- GOV.UK Design System: Error messages Errors users can correct should be explained differently from service problems or conditions they cannot fix.
- GOV.UK Design System: Service problem pages A service failure needs an explanation and practical next steps appropriate to the failure.
- W3C: Status messages Status information should be available to assistive technology without unnecessary focus changes.