Dead-end empty state

Problem Context

• A list, table, dashboard, workspace, inbox, or panel can render with no visible items.
• The product may not yet know whether the cause is first use, filters, permissions, loading failure, deletion, unavailable data, or a hidden prerequisite.
• Users need enough context to decide whether to create, import, clear criteria, request access, retry, restore, or leave.

Selection Rules

• Flag dead-end empty state when a blank area lacks a specific object name, cause, and reachable next action.
• Flag decorative-only empty states when illustration or friendly copy replaces actionable explanation.
• Flag states that show a primary action the current user cannot perform, because a failed action is still a dead end.
• Replace with empty state when the absence is legitimate and the user has a setup, create, import, sample, or request-access path.
• Replace with no-results recovery when visible search, filter, or sort criteria produced zero matches.
• Replace with error state when expected content failed to load, save, sync, authorize, or compute.
• Do not mark the state resolved until keyboard, focus, screen-reader reading order, and post-action transition all give users a real path out.

Required States

• Unexplained blank state that is being audited as the anti-pattern.
• Diagnosed first-use or legitimate absence state with object-specific copy and valid action.
• Filtered or searched no-results state with visible criteria and recovery controls.
• Permission or prerequisite state with explanation and request/setup path.
• Failure state with retry, fallback, or support path.
• Escaped or recovered state after the user takes a valid next action.

Interaction Contract

• A blank or actionless content region is not a valid terminal state.
• The replacement state must name what is absent and why the system believes it is absent.
• The next action must be available to the current user or replaced with a permission/prerequisite explanation.
• If the cause is uncertain, the UI should show loading, retry, or diagnostic recovery instead of pretending the area is empty.
• Focus should not remain on removed content or an inert blank panel after data changes.
• The state must update when content appears, criteria are cleared, access changes, or retry succeeds.

Implementation Checklist

• Track data status separately from rendered item count: loading, empty, no-results, permission, error, and ready.
• Render the surrounding context such as table title, filter chips, workspace, owner, or object type.
• Write a cause-specific heading and short explanation before adding illustration.
• Show one valid primary action or a clear reason no action is available.
• Do not offer create/import/reset/retry controls unless they are permitted and wired to a state change.
• Keep keyboard focus in a useful place after the blank region resolves or changes cause.
• Instrument blank states so repeated dead ends can be found and replaced.

Common Generated-UI Mistakes

• Blank table body with no heading, count, cause, or action.
• Friendly illustration plus vague text such as Nothing here yet with no task path.
• Create button shown to a read-only user and failing after activation.
• No-results caused by filters but active criteria are hidden above the fold.
• Failed load rendered as empty content to avoid showing an error.
• A removed item leaves keyboard focus on a now-empty region with nowhere to go.

Critique Questions

• Can users name what is absent after reading this state?
• Can users tell whether the cause is first-use, filters, permission, setup, deletion, loading, or failure?
• Is the visible next action valid for this user and wired to a meaningful state change?
• Would the same blank copy still appear if the cause changed to error or no-results?