Empty-State Message¶
Interface pattern — instantiates First-Class Absence Modeling
Turns a blank screen into a designed empty state that tells the person why nothing is here and what to do next.
An Empty-State Message is the designed interface shown when a list or screen has no items — human-readable copy plus an affordance (an illustration, a one-line explanation, a primary action) that tells the person why it is empty and what to do next. Its defining idea is that it is the human-facing surface of absence: it turns a blank pane, which reads as "broken," into an intentional, actionable state. Where Absence Reason Enum is the machine code a service branches on, the empty-state message is the copy a person reads — and it frequently renders one of those codes into words a human understands.
Example¶
A photo-organizing app opens to the "Albums" tab. A brand-new user has created none, so the screen is blank — and a blank screen looks like a bug. The empty-state message replaces it with a friendly illustration, the line "No albums yet," a short explanation of what albums are for, and a prominent "Create your first album" button. But a single generic blank would be wrong, because why the screen is empty differs. When a search returns nothing, the empty state instead reads "No photos match 'sunset'" with a "Clear filters" action — offering a way back, not a way to create. And when the album is a shared one the user cannot see, it reads "This album is private," with no create button at all. The outcome: the person always knows whether the emptiness comes from being new, from a filter excluding everything, or from a permission boundary — and each state hands them the right next move.
How it works¶
- One message per cause. The copy is tailored to why the screen is empty — first run, no search match, access denied, or error — rather than a single "Nothing here" reused everywhere.
- A next-step affordance where appropriate. First-run and no-data states offer a creation or onboarding call-to-action; a denied or error state deliberately does not.
- Visually distinct from loading and error. The empty state is styled so a person can tell "there is nothing" apart from "still loading" and "something failed."
- Rendered from a cause. When an Absence Reason Enum is available, the message is chosen from the code, keeping human copy and machine cause aligned.
Tuning parameters¶
- Tone and length — from a terse label to an encouraging paragraph. Warmer, longer copy suits onboarding; a terse label suits a routine "no results."
- Call-to-action presence — whether to offer a "Create" or "Invite" action. Right for first-run; wrong — even harmful — over an access-denied or error state, where it implies a path that does not exist.
- Distinction strength — how strongly empty, loading, and error are visually separated. Under-differentiating them is the classic failure below.
- Illustration vs. plain text — whether to spend a custom illustration on the state or keep it minimal; more polish for high-traffic first-run screens, less for rare ones.
When it helps, and when it misleads¶
Its strength is that a designed empty state is a recognized onboarding and first-run surface rather than dead space — a chance to orient a new user or offer a way forward exactly where a blank would have signaled failure.[1]
Its failure mode is the generic blank: one "Nothing here" shown for every cause, collapsing first-run, no-match, access-denied, and error into an undifferentiated message so the person cannot tell which situation they are in or what to do. A close cousin is offering a "Create" call-to-action over what is actually a masked service error, inviting the user to act on a screen that is broken. The guarding discipline is one message per cause, never a create affordance over an error, and a clear visual line between empty, loading, and denied.
How it implements the components¶
user_facing_empty_state_message— it is the human-readable copy and layout shown to a person when a surface has no items.fallback_or_creation_path— its call-to-action is the way out of the empty state: create the first item, clear the filter, or invite a collaborator.nonvalue_distinction_map— it presents different messages for no-data, no-match, access-denied, loading, and error, so the person can tell the causes apart.
It does not define the machine-readable cause taxonomy or the audit log of absences — absence_reason_code, empty_case_observability — that is Absence Reason Enum; this mechanism renders those causes for humans rather than producing them for machines.
Related¶
- Instantiates: First-Class Absence Modeling — the empty-state message gives absence a legible, actionable form for the person looking at it.
- Consumes: Absence Reason Enum supplies the machine-readable cause the message renders into human copy.
- Sibling mechanisms: Empty Set Literal · Empty Collection Return · Zero-Row Result with Schema · Option or Maybe Type · Null Object Pattern · No-Op Command · Absence Reason Enum · Identity Element Test · Sentinel Value Retirement
Editorial Notes¶
Form Classification¶
Form family: Interface, Display & Cue
Rationale: Empty-State Message operates as a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use because it turns a blank screen into a designed empty state that tells the person why nothing is here and what to do next.
Independent corroboration: The frozen evidence defines Empty-State Message as 'Turns a blank screen into a designed empty state that tells the person why nothing is here and what to do next', so its operative form is Interface, Display & Cue.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction (HCI)
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Interface-content design cohered human-readable empty-state messages that translate machine absence into explanation and an actionable affordance.
Related originating lineages:
- Communication & Media Studies — Plain-language and message-design practice supplies the explanatory copy and framing.
Review resolution: The current reviewers agree that human_computer_interaction is primary. For the reported differences (alternate_origin_disagreement, domain_reach_disagreement), the evidence supports single_lineage, multi_domain, and communication_media_studies; these choices preserve materially formative origins without conflating later domain reach.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Google. Empty States. Material Design (n.d.). Treats an empty state as a designed first-use surface that can orient a new user and offer a way forward. registry ↩ Show verification details
Supported in partVerified against the work's full text
Material guidance says empty states should be designed and suggests starter or educational content that helps new users, but does not call them a recognized onboarding surface.
“The most compelling way for new users to learn and get excited about your app is by using it. Consider providing starter content that will allow users to explore your app right away.”