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.[n1]
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
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.
Notes¶
[n1] "Empty state" is a standard term in interface design for the screen a user sees when a container has no content — a first-run, no-results, or cleared-out view. It is widely treated as an onboarding opportunity rather than an error, precisely because an undesigned blank tends to read as a malfunction. ↩