First-use empty and emptied-after-use empty are different meanings

What it is

The screen can show zero items for reasons that make empty into different objects. Empty-state provenance requires the package to split at least two: this container has never held content (first use), and it once held content that a user or the system then removed (cleared). First use explains what this place is and how the first object appears. Cleared admits the objects were just here, and points at restore, undo, or import again. Shipping both as one welcome illustration treats a person who just emptied the list as a new user, and offers a trash can to someone who has never had anything.

Provenance is the identity the empty frame must carry, not whether list chrome remains at count zero — that is a geometry question. Both origins can guide; they cannot share the sentence and the action.

Why it happens

People interpret empty through what just happened. On a never-used empty there is no “previous list” in working memory, so welcome and create match. On an empty that follows a delete or a broken sync, those objects are still in working memory; a welcome is read as the system swallowing history. What is needed is a time cue (“you just deleted 12 items”) and a reversible action. Given only one empty frame, implementation can wire only one template, usually the first-run welcome that appeared in the file. The cleared path then gets “Get started” at runtime, and undo is never wired because it was not on the frame.

Provenance also decides how empty is allowed to die. First-run empty must leave as soon as the first object is created, or the welcome fights the real list. Cleared empty should keep restore for the undo window, then settle into a stable “it is empty now; you may create again.” One shared frame cannot express both lifetimes, so implementation picks one lifetime and stretches it over every zero.

Where it stops holding

A filter or search that collapses ten rows to zero is a query origin, neither first-run nor cleared. It should go to “no matches, change the query,” not borrow a welcome and not borrow undo-delete. Load failure is not a provenance of empty; the failure frame must be distinguishable from both empties. In a multi-pane product one pane can be first-run while another is cleared — deliver per container; do not fire a global welcome because “there is still an empty.” When demo data fills the workspace, first-run provenance only appears on real accounts; still ship the first-run frame for those accounts, and do not let demo screenshots stand in.

Applying it

• Ship two frames for the same container, conditioned never_had_items and had_items_now_zero. Split further if delete, archive, and unbind need different actions.
• The first-run frame must not show trash, undo, or “restore last.” The cleared frame must not show “Welcome” or “This is your workspace.”
• On the cleared frame, mark how long the undo window lasts and whether restore remains after it. On the first-run frame, mark which layer disappears the moment the first object succeeds.
• Walk the same page with two test accounts: brand new, and one that created three items then deleted them all. If both screens share the welcome illustration or share a trash entrance, provenance is not split. Change the conditioned frames in the design source; do not add isNewUser in code while still rendering the same picture.

Related

• Same group: R2.09.1 An empty state must guide the next step, not only announce absence · R2.09.3 Partial failure and total failure need separate expressions · R2.09.4 Skeleton shapes must correspond to the content they stand in for
• Adjacent: R2.05 Edge-case Completeness in Handoff · I2.08 Load failure
• Search terms: empty-state provenance · first-run versus cleared · empty origin