empty-stateslisted

# Empty States Every reachable data state needs a truthful treatment; absence and failure are different conditions with different safe next moves. ## Start with a state contract, not a set of illustrations Name the region and transition before copy or illustration. Record: | Question | Decision to record | | --- | --- | | User goal | What they came to find, create, compare, or finish in this region | | Data authority | Network source, local draft, cached result, permission boundary, or user-entered filter | | Entry condition | The observable event that enters loading, zero-result, error, stale, or partial state | | Continuity | What remains visible and editable while the state is active | | Recovery | The action that can change the state, its owner, and whether retry is safe to repeat | | Exit proof | The event that replaces the state and the announcement/visual confirmation the user receives | First-use, zero results, and permission absence need different truth. Trusted cached data is stale content with progress—not a blank reset. ## Model the reachable state set Design loading when work can be in flight, empty when a successful result can contain zero items, and error when the region can fail. A static or fully local region need not invent unreachable states. Add stale, partial, awaiting-input, or pending-mutation only when their entry condition exists; never render zero, unavailable, and loading as the same state. ## Loading: communicate the wait honestly Use a la