Review Empty and Error States as Complete Product Journeys

Overview

Review empty and error states as complete journeys: explain the current situation, preserve useful work, and provide the next action the user can actually take. A message is successful when it helps someone continue or understand why they cannot, not merely when it occupies the blank space attractively.

These states often receive less attention than a product's populated dashboard. Yet a new user, a person with limited permissions, or someone encountering a service failure may spend their first session there. The product's value loop must still make sense.

Use W3C's guidance on clear, accessible notifications and GOV.UK's service-error patterns as foundations. The examples below apply those principles to common product situations.

Distinguish the states before writing the message

An empty collection can mean several things: no records exist yet, a filter excludes all records, the user lacks permission, data is still loading, or the request failed. Those situations need different actions.

A generic “nothing here” message can conceal a failure. A generic “try again” button can be unhelpful when the user simply has no matching search results.

Create a state inventory for each important screen. Identify the source of truth and what evidence lets the interface distinguish the states. If the application cannot tell whether data is absent or unavailable, the message should preserve that uncertainty.

This belongs in the MVP definition. A small complete product still needs a coherent path for first use and ordinary failure.

Make first-use emptiness inviting and accurate

For a new workspace, explain what the collection will contain and how to create the first useful item. Use an action label that describes the task, such as “Create a project” or “Import contacts.”

Check whether the current user can perform that action. A button that fails because only an administrator can import data creates an avoidable loop. Offer the appropriate request or setup route instead.

Do not fill the interface with sample data that can be mistaken for real business records. If a demonstration is useful, label it clearly and keep its consequences separate from actual work.

The first-use state should also explain any prerequisite that matters, such as connecting an account or receiving an invitation. Keep implementation details out of the message unless the user needs them to decide what to do.

Help people recover from filters and searches

When a search returns no results, show the relevant query or filters and make them easy to change. Preserve the user's work rather than resetting the whole screen.

Differentiate an empty account from a filtered empty view. “No invoices match these filters” is more useful than “You have no invoices” when records exist outside the selected date range.

Consider permissions and data freshness. A person may reasonably expect a record that another colleague created moments earlier. If synchronization is delayed, explain the known limitation without inventing a precise completion time.

Test clearing filters with keyboard and assistive-technology use. The recovery control should be discoverable in the same context as the empty result, not hidden in an unrelated settings menu.

Keep loading distinct from failure

A loading state should indicate that work is underway without claiming success. Avoid replacing existing usable information with an empty page when a background refresh would suffice.

Decide what happens if loading takes longer than expected. The product may need to explain the delay, allow a safe retry, or provide another route. An endless spinner gives the user no basis for action.

If previously loaded data remains visible, label its freshness where that matters. A stale inventory count or appointment list can lead to a poor decision if it looks current.

Do not expose a retry action that can duplicate a consequential operation. The interface and backend need to agree on whether retrying means checking status or submitting the action again.

Explain validation errors at the right place

A validation error should identify the field or condition that needs correction and explain the accepted input in plain language. W3C's form guidance supports clear error feedback and an accessible connection to the affected controls.

Preserve valid entries. A user correcting one date should not need to retype an entire form.

Where several errors exist, provide a useful overview and a route to each field. Do not rely only on red borders or an icon. People need text that remains understandable without color.

Avoid blaming language. “Enter a date in day, month, year order” is clearer than “Invalid user input.” If the product has a constraint, describe the constraint rather than suggesting that the user should have guessed it.

State what happened to the action

After a submission failure, users want to know whether their action occurred. Separate a confirmed rejection from an uncertain outcome.

For example, “We could not confirm whether your request was received” requires a different recovery path from “The request was not submitted because the attachment is too large.” The first may need a status check before another attempt.

GOV.UK's service-error guidance emphasizes useful next steps and information about submitted answers. Apply that idea to the actual product state: saved draft, unsaved changes, accepted request, or unconfirmed result.

Never claim that information was saved unless the system has evidence. A reassuring but inaccurate message can cause the user to close the page and lose work.

Give permission failures a useful boundary

A permission error should explain that the current account cannot perform the task and identify the appropriate next step where one exists. Avoid revealing information the user is not entitled to see.

If access can be requested, explain whom to contact or provide the supported request flow. If it cannot, offer a relevant route back to work the person can perform.

Distinguish signed-out, expired-session, and insufficient-permission states. Repeatedly asking a signed-in user to log in again will not fix an account that lacks the required role.

Test the return path after authentication. A successful sign-in should preserve or restore the intended task where the product can do so safely.

Write acceptance examples for recovery

Reviewers need more than screenshots. Define the state, the visible explanation, the available action, and the result of using it.

For an empty search, acceptance might mean that the active filters remain visible, clearing them restores records, and focus moves sensibly. For a failed save, it might mean that the draft remains intact and a safe retry produces one saved record.

Use the product feedback loop to find recurring real failures. A support ticket saying “my work disappeared” may expose a missing state transition that a polished happy-path demo never showed.

Include interruption tests in the mobile app launch checklist: connection loss, backgrounding, expired sessions, and returning through an old link.

Review the words with the behavior

Keep messages concise, but do not remove the fact that makes the next action understandable. “Something went wrong” is sometimes an honest temporary fallback; it should not become the final design for every known failure.

Verify that action labels match what happens. “Try again” should retry the relevant operation safely. “Go back” should not discard work unexpectedly. “Contact support” should open a monitored route with enough context to help.

When the state is repaired, the interface should return to an understandable normal condition. Remove stale error messages, preserve the correct data, and announce important changes accessibly.

A strong recovery experience does not require elaborate illustration or a long apology. It requires the product to know its state and help the user make the next informed move.