SaaS empty states: what has your product actually checked?

A returns team opens its review queue at the start of a shift. The page says “You’re all caught up.” Someone moves on to another task. That is a reasonable response to the message, provided the application has actually checked the queue.

Consider a fictional SaaS product used by a retailer operating several storefronts. The same blank area could appear because every return has been reviewed, because a saved filter excludes the remaining work, or because one storefront has stopped sending updates. Each situation calls for a different decision.

Empty states are often discussed as a way to welcome new users. They also matter long after a team has settled into a product. In everyday operations, an empty queue can become evidence that it is safe to stop looking. The interface needs to earn that interpretation.

Give an empty result a clear boundary

In this example, the returns queue contains requests waiting for a first review. Completed requests remain elsewhere in the product. When the latest query succeeds and returns no matching records, “No returns awaiting review” describes the result more precisely than a general celebration.

A nearby label can establish the scope: “All storefronts · Updated at 08:40.” That timestamp should reflect the data behind the result. Showing the time the page loaded would create a reassuring impression without telling the team whether new requests had arrived.

This is a design recommendation for the fictional service, rather than a requirement to put timestamps on every empty screen. Freshness matters here because the team uses the result to allocate its time. In a different product, the meaningful boundary might be a workspace or a reporting period.

Before polishing the copy, the product team needs to know whether the application can distinguish a successful empty response from a failed request. If both become an empty list on the screen, the wording cannot reliably communicate what happened.

A saved view can hide the work people expect

Suppose a supervisor used the queue to review damaged goods the previous afternoon. The product remembers that selection. The next morning, no damaged-item returns remain, but several size exchanges are waiting. The page is empty because the view is narrow.

“No returns match ‘Damaged item’” gives the person a useful explanation. Keeping the active filter beside that message makes it easier to connect the result to its cause. An action labelled “Show all return reasons” offers a direct way to widen the view.

The action should change what its label promises. Removing every filter, including the storefront the person is responsible for, could replace one confusing result with another. Preserving the rest of the view also respects work the person has already done to organise the queue.

The Carbon Design System’s empty-state guidance separates missing data, outcomes of user actions, and errors. That distinction is useful when a reusable component tempts a team to put the same sentence everywhere. A reusable layout can still carry a different explanation and action for each cause.

Waiting deserves its own message

Now imagine the supervisor switches storefronts. While the application fetches the new queue, it briefly displays the congratulatory empty state. A moment later, six requests appear. Even if the pause is short, the product has described unfinished work as a completed result.

A loading indicator should communicate that the answer is still on its way. If the interface keeps the previous queue visible during refresh, it should make clear that those records belong to the previous view. Otherwise, a person may start reviewing a request while believing the new selection has already taken effect.

The transition matters as much as the resting screen. Successful queries can produce records or an empty result. Failed queries need an explanation that the product could not retrieve the queue. Those outcomes should remain distinct when the connection is slow as well as when it is fast.

The same changes need to be available to people using assistive technology. W3C’s guidance on status messages covers updates such as a search in progress or a search with no results when they appear without a change of focus. Appropriate status semantics can communicate the outcome while letting the person stay in the task.

Partial information should stay visibly partial

A more difficult case occurs when two storefronts respond and a third cannot be reached. The responding stores have no returns waiting for review. Showing a clean, empty queue for the combined view would hide the missing part of the answer.

The product could say, “No returns awaiting review from the two connected storefronts. We couldn’t retrieve requests from the outlet store.” If it allows the team to continue with that partial result, the limitation belongs beside the result for as long as it applies.

Where a previous successful response is available, retaining it may help the team continue some work. It needs a clear label showing that it is older information. Whether that is useful depends on the task: a stale queue may support preparation, but it may be unsuitable for decisions that require the latest status.

SAP Fiori’s empty-state guidance connects the explanation of missing content with an appropriate next action. In this situation, retrying the unavailable storefront is relevant. Suggesting that the user create a return request would solve a different problem.

Review the decision the screen produces

A useful review starts with the work someone expects to do. Prepare the same queue with a genuinely empty result, a restrictive filter, a pending request, and a partial failure. Show each version separately to someone familiar with returns processing and ask what they would do next.

Listen for the conclusion behind the action. A person who moves on because all relevant requests were checked has understood the screen. A person who moves on because a retrieval failure looked like a completed queue has been misled, even if they found the wording friendly.

Once a revised state is in use, feedback such as “new requests disappeared” becomes more useful when it includes the active view and whether the latest refresh succeeded. Capture only the context needed to investigate. Customer details and the contents of individual return requests may be unnecessary.

There is no need to add an action to every empty space. Sometimes the team really has finished its work. A well-designed empty state lets people move on with a clear understanding of what the product checked, and of anything it could not yet establish.