An empty screen is not always a first-use screen. A search can return no matches. A filter can hide everything. A permission change can remove access. A sync can still be running. Treating all these situations as “Nothing here yet” leaves the person to diagnose the product before continuing their work.
Imagine opening a shared research folder and finding no references. You need to know whether the folder is new, whether someone removed its contents, or whether you cannot see them. A cheerful illustration does not resolve that uncertainty. The message needs to explain the state and offer an appropriate next step.
Separate absence from failure
Before writing copy, list the possible reasons for the empty area. Group them by what someone can do next. A new folder may need an Add references action. An unsuccessful search may need different terms or a wider scope. A network failure needs a retry and an honest indication that the request did not finish.
These states should have different messages even when they share a layout. Do not show a confident zero-result message while a request is still loading, and do not keep previous results under a new query after that query fails. Both behaviors make the interface tell a story the underlying request does not support.
Give the message three jobs
A useful empty state answers three questions: What happened? Why might it have happened? What can I do now? The second answer can be short, and it should acknowledge uncertainty when the product does not know the cause.
For a filtered catalog, try a heading such as “No Android checkout flows match these filters,” followed by “Remove a component filter or search across all platforms.” The action should perform that change without silently discarding the rest of the query. Keep an accessible way to inspect the active filters so the explanation is verifiable.
Keep the action close to the situation
A general Create button is not always the right response. If a person is browsing a folder shared by someone else, they may lack permission to add items. If an import is pending, creating another import could duplicate work. Match the action to the state and the person's role.
For reversible changes, consider offering an undo or a clear return to the previous scope. For a destructive action that emptied a view, explain where recovery is possible. Avoid suggesting recovery options that the product cannot actually provide.
Research the transition as well as the screen
Collect references for the moment before the empty state and the first successful action afterward. In Refcat, compare how similar products move from an empty collection to its first saved item. Notice whether instructions disappear, whether the primary action stays in the same place, and whether the content shifts unexpectedly.
Create a small review table with a row for each state: cause, message, available action, and successful outcome. Walk through it with realistic data, including a failed request and a restricted account. A blank screen that teaches the next step can be useful; a blank screen that hides the actual condition is a debugging task handed to the user.