empty-stateslisted

# Empty States Every reachable data state needs truthful treatment; absence and failure need different next moves. ## Start with a state contract, not a set of illustrations Name region and transition before copy/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 success can contain zero items, and error when the region can fail. Static/local regions need not invent states. Add stale, partial, awaiting-input, or pending-mutation only when their entry condition exists; never merge zero, unavailable, and loading. ## Loading: communicate the wait honestly Use a layout-matching skeleton when final geometry is known and it aids orientation. Use determinat