Practical framework / 5 MIN READ
Make empty states explain what happens next
Identify why an application area has nothing to show before choosing a message or inviting the reader to create more data.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
An empty view can mean no records exist, the work is complete, access is limited or information has not loaded. Those meanings require different explanations and next steps.
What you will leave with: Leave with an empty-state evidence map that prevents the interface from treating every blank area as a new-user problem.
Use this when
- A dashboard shows a generic no data message.
- A completed work queue looks like a broken page.
- Users are asked to create records they may not have permission to create.
This lesson excludes store-search recovery and broad onboarding strategy; it focuses on accurately representing absent application content.
List the reasons the view can be empty
Work with the product and implementation owners to distinguish no records, completed work, unavailable data and permission-limited views. Carbon's design guidance treats empty states as situations with different causes and treatments. Build a map connecting each visible state to evidence the system can actually observe. Do not claim that an organization has no records when the current user merely cannot see them. If the system cannot distinguish causes, resolve that limitation or use a carefully bounded explanation. A friendly illustration cannot make an unsupported diagnosis accurate.
Explain what normally belongs here
Name the type of information the area contains and why it is absent under the verified condition. Keep the explanation proportionate to the space and task. A work queue with no outstanding items may need a simple completion statement and a route to history, while an unconfigured report may need a setup prerequisite. Avoid filling every empty panel with a tutorial or promotional message. The reader should be able to tell whether the absence is expected, temporary or requires action without decoding an icon or guessing from the page title.
Offer only a valid next action
Decide whether the useful response is create, configure, check access, wait, return to another view or do nothing. Verify that the person has the authority and capability to use the offered action. Do not make an upgrade or data-creation prompt the default when the actual cause is a service problem. Preserve privacy when access is restricted; a message should not reveal the existence of confidential records unnecessarily. Distinguish a successful empty state from a failure so the reader is not pushed into unnecessary work after completing the task they came to do.
Test state transitions and realistic roles
Use safe test accounts and fixtures to reproduce each cause, including a role with limited access and a queue that becomes empty after completion. Check the transition from loading to empty so a brief delay does not flash a false no-records claim. Verify that the message disappears when content becomes available and that the action leads to the correct place. Review the experience with accessibility expertise where state changes need announcement. Keep the state-evidence map attached to the component specification so later reuse does not collapse the distinctions back into one generic placeholder.
Make the reasoning concrete.
A hypothetical editorial application displays articles awaiting review.
Generic empty prompt
Opening: The panel says no articles yet and invites the reviewer to create one.
Hypothesis: The view contains an obvious action.
Risk: The reviewer may have finished all assigned work or lack access to other articles, so the message misstates the situation.
Verified completion state
Opening: The application says no articles are currently assigned for review and offers the permitted history view.
Hypothesis: The message matches the user role and observed state.
Risk: It should not imply that the whole organization has no unpublished articles.
The team tests new, completed, loading and restricted states separately and gives each an evidence-backed explanation.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Cause
Which verified condition makes this view empty?
Scope
Does the message describe this user, this view or the whole system?
Expectation
What information normally belongs here?
Action
What useful next step is actually available to this person?
Transition
How will loading, completion and new data change the message?
Watch for the wrong conclusion.
- Treating every blank view as first-time use.
- Claiming no records exist when access is restricted.
- Offering creation or upgrade when the service is unavailable.
- Flashing an empty message before loading has finished.
Your next action
List every cause of emptiness for one application panel and pair each with evidence, a bounded message and a valid next action.
Sources & scope
The framework, examples and suggested checks are original editorial synthesis. Hypothetical examples are not measured results. Source checking is not an independent audit or a guarantee of business outcomes. No named human reviewer is claimed.
- IBM Carbon Design System: Empty states →Primary publisher guidance · Supports: Supports distinguishing reasons why no data is displayed and matching the message to that state. The state-evidence map is original analysis; design-system advice does not prove a business outcome.