Empty states need an explicit next action

What it is

A next action in an empty or zero-result state is not an arbitrary call to action. It is an executable recovery path derived from the evidence for the current state, the person's permissions, and the task they were pursuing. A genuinely empty collection may support creating or importing; no match calls for revising a query or relaxing conditions; a failure may support retry or an alternative route; lack of access permits only safe actions that actually exist. Recovery should also preserve work already invested in the query, filters, sort order, scope, and drafts.

“Explicit” does not mean every state needs one primary button. When the result is a legitimate endpoint, the person has no available action, or the system cannot safely offer one, an accurate explanation is better than a dead or misleading control.

Why it happens

An action becomes useful only when it matches both the cause of the state and the capabilities available now. A true empty state can lead to create, import, or setup if the current role and entitlement allow them. No match can lead to editing the query, removing a particular filter, or broadening scope without resetting the whole workspace. A failed request can be retried when the operation is idempotent or otherwise controlled. An access state can offer sign-in, workspace switching, access request, or a return to permitted content without revealing whether protected resources exist. Loading may support waiting or cancellation, but not a premature claim that nothing exists. Partial success should retain available data and recover only the affected range.

The label and its handler form one promise. A clickable button that fails a permission check, a filter reset that also erases the search term, or a retry that duplicates an item all break that promise. Capability and prerequisite checks therefore belong before presentation, while reversible changes need a stated scope plus a return path or undo.

Studying it

Inject true-empty, user-cleared, no-match, timeout, offline, partial-success, expired-session, forbidden, and prolonged-loading states. Give participants a concrete goal and observe whether they can diagnose the state, choose an appropriate action, and resume the task. Record action discovery, first choice, recovery completion, backtracking, time, accidental resets, and duplicate creation.

Do not stop at the click. Ask participants to revise filters, enter setup, retry, and return; verify that queries, filters, sorting, selected scope, and unsubmitted input survive. Test keyboard and screen-reader use for programmatic association among the status, action name, and destination. Hold backend state and permissions constant across variants so recovery differences are not falsely attributed to wording.

Where it stops holding

“Clear filters” is valid only when filters caused the no-match state, and it should identify what will change; correcting the query may instead be the right action. High-consequence submissions, payments, and irreversible operations must not retry automatically after failure. Some informational endpoints have no sensible action, and some permission states cannot expose a request route; a disabled button is not a substitute.

The focus here is the action contract after an empty state. Error messages separately need a complete account of what happened, why, and what to do; general button-label rules also apply across controls. Timing and visual treatment for loading belong to feedback-component design, although the state machine must still distinguish loading from a completed empty result.

Applying it

Build an evidence–capability–action matrix for every state, with backend status, authorization or entitlement checks, and frontend handlers consuming the same reason codes. Before rendering, verify that the action exists, is enabled and reachable, and does not exceed authority. Define idempotency keys or duplicate-submission protection for retries. Store query, filters, sort, selection, and drafts as recoverable state when a person removes conditions, broadens scope, or leaves the page, then restore them on return or undo.

On no-match screens, show the active conditions that can explain the result and let people edit or remove them individually. If “Clear all” is offered, preview its scope and make it reversible. End-to-end test every action across relevant roles, plans, networks, and devices, including focus movement, status announcements, and accessible names. Monitor empty-state exposure, unavailable actions, successful recovery, duplicate submission, and context loss; repair a bad state mapping before polishing encouragement.

Related

• Within this group: [[T2.05.1 Distinguish no-data, no-match, and error states]] · [[T2.05.3 Explain what filling it in will get you]]
• Related entries: [[T2.01.1 Button text should describe the specific action that will happen]] · [[T2.04.1 Say what happened, why, and what to do]]
• Search terms: empty-state action, zero-result recovery, filter preservation, idempotent retry, permission action