How to Design Empty and No-Results States

A blank project list can mean that someone has never created a project. It can also mean that their search found no matching projects. Those screens may contain the same empty rectangle, but they call for different explanations and different actions.

The practical difference between an empty state and no results is the reason content is absent. A genuinely empty collection usually needs a way to begin or an explanation of how content arrives. A no-results view needs a way to revise the query, filters, or scope that hid otherwise available content. Sending both people to “Create a project” can turn a simple search problem into duplicate work.

No results is one kind of empty state. The useful distinction is between an empty collection and an unsuccessful query: the first changes when content arrives; the second changes when the request changes.

Ask what would make content appear

Before writing a heading, finish this sentence: content would appear here if the person did what? The answer is often enough to separate a useful empty view from a generic one.

If the answer is “created their first project,” the screen can explain what a project contains and offer that action. If the answer is “removed the Archived filter,” the screen should help them change the filter. If the answer is “waited for a request to finish,” the interface is still loading. If the answer is “regained permission,” a creation button may be irrelevant or unavailable.

This question also prevents a common copy mistake: treating the absence of visible rows as proof that no data exists. The view may know only that no accessible records match the current request. Its message should reflect that knowledge rather than make a stronger claim about the entire workspace.

The Nielsen Norman Group article on empty states describes the value of explaining system status and providing an appropriate route into a task. It also warns against showing an empty-result message while content is still loading. That foundation is useful; the specific decision still depends on what your application knows about the current collection and request.

Power BI explains how content arrives; NexTag shows why hierarchy matters

NN/G’s empty-state article includes a Microsoft Power BI recent-items view that explains how content gets there: opening content makes it available in Recents. The important detail is causal. The view does not imply that the whole account is empty or that the person must create something new.

A contrasting case appears in NN/G’s no-results research. On a historical NexTag search page, a participant overlooked the small no-matches message and looked at the more prominent content below it. The eye-tracking plot recorded no fixations on the message itself. Recovery suggestions existed, but the participant had missed the reason for needing them.

The lesson is not that every empty view needs a huge heading. Power BI’s message has a local job: explain a view within an existing workspace. A search-results page must interrupt the expectation that the main area contains matching results. Give the status enough prominence for its context, then make the next useful action easy to find. Decorative illustrations and unrelated recommendations can undermine that sequence even when the copy is technically present.

Choose the state from facts, not an empty array

A zero-length response is not enough to choose the interface. The request could be pending, failed, restricted or successfully empty. In a real implementation, the message should be selected from the request status and scope as well as the visible record count.

This table becomes especially useful when reviewing transitions. Enter one query, immediately replace it with another, and let responses return in the opposite order. The view must show the state of the active request. An old empty response should not erase the newer successful result. That is a data-flow defect; another illustration will not fix it.

A practical review question is “What would you do now?” Show the screen without describing its state first. If a person chooses Create because they cannot find the retained query, the recovery controls need attention. If they wait because the view looks unfinished, clarify whether processing has ended. Record the interpretation, not only whether someone clicked the intended button: an accidental correct click can hide a misunderstood state.

Write for the cause of the empty view

First use: a credible beginning

A first-use view should help someone understand the object they are about to create. “Nothing here yet” acknowledges the blank space, but it leaves the purpose of the area unexplained. “Keep project briefs, links, and review notes together” gives a new person a more concrete reason to start.

Pair that explanation with an action the person can actually take. If creating a project requires a name and nothing else, “Create project” can open that small first step. If setup requires connecting an external service, the action should name that connection instead. A button that sounds easy but opens an unexpectedly complex setup flow can create a new problem immediately after solving the empty one.

The amount of explanation should match the person’s likely familiarity. Someone opening a project workspace for the first time may appreciate a short example. Someone who has deliberately deleted the last saved search probably does not need an introduction to searching. The collection is empty in both cases, but their knowledge is different.

Be careful with sample content. Demonstration rows can make a concept tangible, but they should be unmistakably labeled as examples and should not masquerade as the person’s own data. If the sample project includes a “Client approved” status, a reviewer should not be able to mistake it for a real approval. The empty state should reduce uncertainty, not replace it with attractive fiction.

No results: revise the request

“No results found” tells someone the search ended, but leaves the reason and recovery unstated. A useful no-results message preserves the relationship between the request and its outcome. For a search, keep the entered query visible and editable. For filtering, keep the active filters visible. Otherwise the person has to remember what they asked for before deciding what to change.

A clear heading for our example might be “No projects match ‘autumn launch’.” If the date filter is the likely restriction, the explanation can say, “The current date range is 1–7 October.” That is useful information even when the application cannot know whether the query or date range is responsible for the absence of matches.

Choose recovery actions that alter the relevant condition. “Clear date filter” is more precise than “Start over” when one date filter is active. “Clear all filters” is appropriate when it really removes all filters; if it leaves the query intact, its wording should make that distinction understandable. A reset that silently changes both search and filter scope can surprise people who intended to change only one thing.

The Nielsen Norman Group guidance on no-results search pages recommends making the outcome obvious, keeping routes forward available, and avoiding a tone that mocks the person. Apply those principles to the task in front of you. A project search, a product catalog, and a legal document library do not need the same suggestions or imagery.

If you show suggested alternatives, explain what they are. “Related projects” should not look like results for the unsuccessful query. Place the no-results explanation before the suggestions and give the alternative collection its own label. The person should not have to reverse-engineer why seemingly irrelevant items appeared after searching for something specific.

Use copy that says only what the system can establish

“No projects exist” is a broad statement. “No projects match these filters” is narrower. “No projects are visible to you in this workspace” expresses a different boundary again. Choose between them based on evidence available to the interface, not on which sentence fits neatly on one line.

This matters in systems with private or restricted content. An empty result does not necessarily mean an object is absent. It may mean that the person cannot see it. The product team needs to decide what can be disclosed and which recovery actions are appropriate. The design should not reveal the existence of confidential records just to make an empty message more specific.

Even without permissions, a view may have an incomplete picture. Search indexes can update after content is saved, and imports may still be processing. If the application knows an import is running, it can describe that condition. If it does not know, avoid inventing a reassuring promise that the missing items will appear shortly.

For the fictional workspace, write a small copy rule: a successful query with zero matches can produce “No matching projects”; a confirmed collection count of zero can produce “No projects yet.” A failed query produces neither. This simple distinction prevents a network problem from borrowing the optimistic tone of first use.

Preserve enough structure to make the next action easy

An empty view can be visually calmer than a populated list while still keeping useful controls in place. Search, filter chips, the page title, and the collection scope help explain where the person is. Removing them all in favor of a centered illustration may make the screen attractive but harder to recover from.

For our no-results project list, keep the search field at the same location and leave the selected workspace visible. Place the explanation in the area where results would normally appear. The person can then revise the request without hunting for a control that moved because the result count changed.

A first-use screen has more freedom. There are no rows to compare, and a larger introductory message may be appropriate. Even then, maintain familiar navigation and a clear page title. The person should know whether they are creating a project for their personal space or a shared team space before they press the button.

Avoid making the visual footprint depend on a single short English sentence. Test longer project names, longer translated messages, and filters that wrap over two lines. Empty views are often designed at comfortable desktop widths and then squeezed into narrow side panels. A design that works only with “No items” is not ready for realistic content.

Choose the action with the lowest useful cost

A recovery action should make progress without unnecessarily discarding work. If the person has carefully selected a workspace, a date range, and an owner, clearing everything is a large reset. It may solve the absence of results, but it also destroys the context they were trying to investigate.

Offer a smaller change when the system can support one. Removing an individual filter can be more useful than clearing the entire request. Expanding a date range can preserve a relevant keyword. Returning to the parent folder can be more informative than sending someone to the application’s home page.

Do not imply that the smallest action is guaranteed to succeed. “Remove the date filter” honestly describes an operation. “Show your projects” promises an outcome the interface may not know it can deliver. If a preview count is available and reliable, the product can make a stronger suggestion; otherwise keep the action label factual.

Creation may still be useful on a no-results page, but it usually needs a supporting role. Someone might search for a project before deciding to create it. Offer that route without making creation look like the only recovery path. In a system where duplicates are costly, consider explaining that the search covered the current workspace rather than suggesting a new object too quickly.

Walk through the same page over time

The most revealing review is a short sequence, not a collection of isolated empty screenshots. Begin with a populated list, apply a filter that produces zero matches, clear the filter, and confirm that the original list returns. Then create a genuinely empty collection and compare its message and action.

In the fictional workspace, a person begins with six projects in the current collection. They select an owner who has no projects during the chosen week. The result area says there are no matches and leaves the owner and date controls visible. Clearing the date filter restores any matching projects across the wider period, while preserving the owner selection.

Now move to a new workspace with no projects. The same result area introduces the purpose of projects and offers creation. Clearing filters is unnecessary because no filters are active and the underlying collection is empty. The interface can share typography and spacing with the first state without sharing its message.

These are implementation questions as well as design questions. A static comparison can specify the desired behavior, but the working application needs tests for request timing and state changes. Keep the review focused on that small journey rather than expanding it into an unrelated catalog of every possible interface state.

Match the tone to the situation

An empty personal favorites list can feel light and welcoming. An empty audit log during an incident investigation should be calm and precise. The same smiling illustration and “Let’s get started!” line would not serve both situations well.

Consider the person’s most likely concern. A new user may ask, “What belongs here?” Someone searching for a known file may ask, “Did I lose access, choose the wrong location, or type the wrong name?” Someone reviewing completed work may simply need confirmation that nothing remains. Tone becomes easier to choose when the underlying question is explicit.

Do not congratulate the person merely because a list contains zero rows. An empty task queue might mean all tasks are finished, but it might also mean a filter is hiding them. Celebration requires a confirmed positive condition. If the application cannot establish that condition, a neutral explanation is more trustworthy.

Likewise, avoid apologizing for ordinary first use. There is nothing inherently wrong with a new collection having no records. Save interruption language for actual interruptions, and make routine empty views feel like a normal part of using the product.

Make illustrations earn their space

An illustration can explain what will appear in a collection or help differentiate a first-use view from a search outcome. It should not push the useful action below the fold or make the page feel like a dead end. If removing the image makes the message easier to understand, revise the composition rather than defend the decoration.

For the workspace example, a restrained line drawing of a project card can show the kinds of information a project holds. A no-results view may need only a small search-related symbol because the query and filters already supply the context. The two states can share a visual family without using the same large picture.

Keep essential explanations as real interface text. An illustration can reinforce the relationship between a filter and a result, but the copy must still make sense when the image is unavailable. This is especially important when an image contains tiny labels that look sharp in a design file and become unreadable in a narrow layout.

Review the distinction in OpenDesign

A supported HTML preview in OpenDesign can make these alternatives easy to compare. Build the empty collection and no-results examples with realistic copy, adjust text or styles manually, and inspect them using viewport presets. Comments sent into chat can identify the exact message or action that needs revision.

For a useful review, ask someone to explain what happened on each screen and what they would do next. Do not introduce the screens as “first-use state” and “filtered empty state” before asking; those labels give away the answer you need the design to communicate. If both screens produce the same interpretation, the difference is not yet clear enough.

Verify the data conditions in the working application too: the active query, permission scope and filter reset must select the message reviewed in the design.

A small decision that prevents a larger misunderstanding

Before approving an empty area, read its heading as a factual claim. Then check whether the application knows enough to make that claim. Read its main action as a promise about what will change, and check whether the control actually makes that change.