When an admin list is empty on first open and users keep waiting for it to load, is the empty state failing to tell them they can create one?

When an admin list has no records on first open, if all that remains is a blank white screen, users usually will not think "there is simply no data here." Instead, they will first wait for it to load, then refresh, or suspect they lack permission. What an empty state needs to solve is not whether it looks good, but three things: why it is empty, whether this emptiness is normal, and what to do next. According to common 2026 delivery practice, container-type pages such as lists, search results, dashboards, and message centers are all worth configuring with an empty state, but the depth of content should be separated by cause—using the same image across all pages is not recommended.

What problem does an empty state actually solve?

An empty state is the display form a page takes when there is no content to show. It usually covers four types: no data on first visit, no results from filtering or search, no visibility due to insufficient permission, and loading failure. It replaces containers that are meant to hold content—tables, lists, cards—so it is essentially a state explanation, not decoration. Many teams mix it together with loading and error states, so the page has only one kind of "nothing here" appearance, and users cannot tell whether it has not loaded yet, truly has no data, or has errored.

To judge whether an empty state is qualified, see whether it can answer three questions: why it is empty now, whether this emptiness is normal, and what I can do next. If it cannot answer all three, it is just a placeholder. Also note that an empty state is only for scenarios with a container but no content; if the entire module should not appear at all, hide it directly instead of leaving an empty box with a line of text.

Why a blank page is mistaken for a broken system

Blankness itself is ambiguous. A user's default experience is often "the page is still loading," so their first action is to wait or refresh, rather than to think "there is no data here." This is especially obvious on admin pages: a table that is usually full of records one day opens as a blank white screen, and users find it hard to tell whether their filter conditions changed, the data was cleared, or the service is down. This uncertainty leads to repeated actions: refreshing again and again, restarting the page, or asking customer support.

The more practical cost is support overhead. When an empty state is missing, the same type of question keeps appearing in customer support and chat groups, even though a single sentence on the page could clarify it. Conversely, an empty state that explains the cause can reduce follow-up questions like "is it broken?" and can conveniently guide users to the next action, such as creating a new item, clearing filters, or contacting an admin.

Split empty states into four types by cause

Making all empty states look like the same image saves effort at delivery, but it ignores the fact that the causes of "empty" differ, and so do the user's next steps. Below, we break them down by cause; each type has different goals, copy tone, and action entry points. The point of classification is to let developers know that the same component needs different parameters, not to make designers draw several extra sets of images.

1. First-time empty: The goal is to guide creation. Copy should be positive and provide a primary action button, such as Create, Import, or Add one. Be careful not to erase the sense of guidance with a neutral phrase like "No data."
2. Conditional empty: The goal is to help users loosen conditions. It should echo the current search term or filter conditions and provide exits such as "Clear filters" or "Reset conditions," so users do not think the entire database has no data.
3. Permission empty: The goal is to explain the restriction. Write clearly whether it is no permission or permission must be requested; do not cover it up with "No data," or users will keep trying. Whether to provide a request entry point depends on internal processes.
4. Failure empty: The goal is recovery. A retry button must be provided, and it should state whether it is a network or service issue; it cannot share the same copy as "truly no data."

The key is in the second step: conditional empty and first-time empty look similar, but the user's next action is completely different—one is to "loosen conditions" and the other is to "create content." Merge them, and after filtering users will see "No data" without knowing they should clear conditions, ultimately misjudging that data has been lost. At delivery, first mark in the requirements which categories each list belongs to, then decide component parameters.

How to trade off illustrations, copy, and buttons

The depth of empty state content does not have to be uniform; it can be layered by frequency of appearance and page importance. High-frequency empty states, such as filter results used every day, are suitable for minimal treatment—one or two sentences of copy plus one exit is enough. First-entry guidance-type empty states can be slightly heavier, with a simple illustration and primary button. Failure states prioritize recovery efficiency; illustrations are optional. The criterion is: how long users stay on this page, and how heavy the decision they need to make is.

The differences among the three forms below mainly lie in production cost, launch cycle, and applicable audience. The numbers are all experience ranges and will vary by team and asset situation.

• Minimal copy type: One line of explanation plus one text entry. Low production cost and fast loading; suitable for high-frequency filtering and secondary modules.
• Image-and-text guidance type: A small illustration or icon plus title, explanation, and primary button. Suitable for first-time empty and important dashboards; typical production cycle is about an additional half to one working day.
• Recovery type: Copy plus a prominent retry button, illustrations can be omitted. Suitable for failure states; the focus is on letting users click the right thing on the first try.

Illustrations are not better the more there are. Excessive decoration makes people think the page content has already loaded, which weakens the signal that "there really is nothing here." At the same time, large images on small screens easily squeeze copy and buttons, and touch targets become smaller. An experience-based practice is to control illustration height, ensure buttons are visible on the first screen, and keep copy from folding into a long block on narrow screens.

Where empty states often get stuck during delivery

A common situation in projects is: requirements only cover the main flow, and the empty state is classified as "patch it before launch." By the integration testing stage, people discover that assets are not ready, copy is not finalized, and no one owns the permission branch. The constraints are usually three: design assets are not yet scheduled, the backend cannot obtain accurate failure reasons, and the timeline has already compressed to a few days before launch. A more reliable approach is to lock down during feature review "which categories this list needs," have developers reserve parameter slots, have design output only shared container styles, and leave final copy to product sign-off.

The cost is also direct: if patched after launch, the four types of empty states are often compressed into a single "No data," and splitting them later requires changing component logic, commonly leading to a round of rework and a version delay. According to 2026 delivery habits, empty states should enter the acceptance checklist together with lists and tables, rather than being treated as visual finishing. In terms of experience range, if the four categories are clearly marked during prototype review, subsequent rework can usually be kept very low; if patched only after integration testing ends, it commonly adds an extra round of front-end/back-end integration testing and a delayed acceptance.

Applicable scenarios and boundaries

Container-type pages are suitable for full empty states: admin lists, tables, search results, message centers, dashboards, favorites, and shopping carts—modules that "have a content slot but may temporarily have no content." Empty states in these places can directly reduce misunderstandings and follow-up questions, with relatively certain benefits, and should also be written into the delivery acceptance checklist, checking copy and entry points item by item.

Cases that do not need one, or should be directly hidden, must also be written clearly: entire modules that should not appear at all, such as when there is no permission and even the entry point is not displayed; content areas that will never be empty, such as fixed configuration items; and deep pages with extremely low traffic. Forcing illustrations into these places only increases loading size and maintenance burden, and users may not even see them. The criterion can be simpler: can this container possibly have a "normal but empty" state? If yes, configure one; if no, do not.

Frequently asked questions

Can empty state and loading state be merged into one?

Merging is not recommended. A loading state means "content is coming soon," while an empty state means "content is not coming." The two give users opposite expectations, and their appearance and copy should be separated, otherwise users will keep waiting.

Can search-no-results and a list that simply has no data share the same empty state?

They cannot share one. The former needs to echo the search term and provide a clear entry, while the latter needs to guide creation. The user's next action differs, and merging them will make people mistakenly think data has been lost.

In an empty state, is a larger and more prominent illustration always better?

No. Illustration height should be controlled so that on narrow screens it does not push the button off the first screen, touch targets should still be large enough, and excessive decoration will instead make people think the content has already loaded.

If data is invisible due to no permission, should an empty state also explain it?

It depends on whether the entry point is retained. If the entry point is visible, it should clearly state whether it is no permission or permission must be requested, and should not cover it up with "No data"; if the entry point is not displayed at all, there is no need for an empty state.

Is it enough to write only "No data" in the empty state copy?

Usually not. A qualified empty state must clearly explain why it is empty, whether this emptiness is normal, and what to do next; writing only "No data" answers none of the three.

When implementing, start by picking a high-frequency list as a pilot: mark the possible causes of emptiness it may have, define copy and exits separately for the four types—first-time, conditional, permission, and failure—then add them to the acceptance checklist. This is suitable for admin projects with lists, search, and permission branches; if it is only a single-page display and the content will not be empty, there is no need for dedicated effort. It is recommended to write the empty state acceptance criteria into the delivery checklist and check them item by item to avoid patching after launch.