Deciding what an empty screen should show

Identify why the view is empty

“No data” can conceal several conditions: nothing has been created, a filter matches nothing, loading is still in progress, or a request failed. Each condition needs a different explanation.

Map first use, no results, loading, failure and restricted access alongside the populated state. Identify the response or action that produces each one. This also gives implementation and testing a concrete state model.

Do not turn a failed request into an apparently empty collection. People may conclude that existing records disappeared. Distinguish absence from an inability to retrieve information.

Pair the explanation with a useful action

On first use, explain what will appear here and connect the explanation to an initial action. Someone without creation permission needs a different path, such as contacting the person who can provide access.

For no search results, retain the query and filters and offer a reset or a broader scope. For an error, explain whether retry is available and whether input is preserved. Restricted access should not be described as an empty database.

Choose one likely next action before adding alternatives. Sending someone to a broad settings area often creates another decision instead of resolving the current one.

Prioritize context and information order

An illustration can help, but the message must explain the state. Let the heading name the condition, the description explain it and the action provide the next step. Avoid repeating the same statement in all three.

A first-time explanation may need more detail than a no-results message encountered repeatedly. Check the actual container: a large illustration can push useful controls out of a small panel.

If sample data is shown, distinguish it clearly from real records. Verify that it explains the product without implying that someone has already created those records. Filling space is not itself a useful outcome.

Exercise the states and transitions

Exercise the real conditions rather than reviewing screenshots alone. Use a new account, eliminate search matches, fail a request and sign in with a restricted role.

• Create the first item and verify the list updates.
• Clear filters and confirm the previous results return.
• Check retry behavior for duplicate requests and flicker.
• Reach the next action with a keyboard.

These transitions make an empty state part of the product workflow. Its job is complete when the user can understand the situation and continue appropriately, not merely when the blank area has text.