The empty screen is part of the product.
Before there is a library, a dashboard, or a full page of results, there is an empty state. Give it a useful job too.
The populated version of an app is easy to show. The shelves contain books. The dashboard contains tasks. The search results have just enough variety to make the layout interesting.
A new person often meets a different version: nothing is there yet.
That is not an absence of design. It is an opportunity to explain where they are, what is possible, and what happens next.
Empty can mean several things
A collection can be empty because nobody has added an item. A filtered view can be empty because nothing matches. A page can also appear empty because the data has not loaded or a request failed.
Those situations need different responses.
“Add your first item” makes sense for a new collection. It is misleading when the collection already contains a hundred items but the active filter excludes all of them. In that case, explain the filter and offer a way to clear it.
Do not collapse a connection problem into a cheerful invitation to begin. Someone should not have to wonder whether their existing work has vanished.
Offer the smallest useful next step
For an imaginary reading app, the first screen might invite someone to add one book. It does not need to introduce every shelving option, reading statistic, and account setting at the same time.
A good first action should leave the person with something real. One item added successfully is a better orientation than a tour they must remember later.
Sample data can help explain a layout, but label it and make it easy to remove. A demonstration collection should not be mistaken for information belonging to the user. It also should not obscure the path to creating the first genuine entry.
The aim is to reduce uncertainty, not to decorate the absence of content.
Keep the explanation available to everyone
Suppose someone changes a filter and the results disappear. A visible message can explain what happened, but the update should also be available to people using assistive technology.
W3C’s guidance on status messages covers updates such as “No results returned” that can be communicated without moving focus. Its technique for using a status region provides one implementation approach.
That does not mean announcing every decorative change. Choose the information that explains the outcome of the person’s action. Keep keyboard focus predictable, and test the actual interaction rather than assuming a label alone solves it.
Review the states that do not make the screenshot
Try the first visit, the first successful addition, a filter with no matches, a slow response, and a failed request. Read each message without the surrounding design and ask whether it describes the right situation.
Make sure retrying a failed operation does not invite someone to add the same thing twice. Make sure dismissing a message does not remove the only explanation of what went wrong.
These are small details, but they belong to the useful part of the product. They are also a good example of how a focused tool can be complete without becoming crowded with features.
An empty page should not make someone feel that they arrived before the application was ready. It should help them take the next step.