States
A screen is never just its "everything worked" view. Loading, empty, error, and offline are part of the design — not afterthoughts. The fastest way to lose a first-time user's trust is a screen that goes blank or silent when something isn't ready.
The system states
Loading
Empty
No sales yet
Record your first sale to see it here.
Error
Offline
How to handle each
- Loading — show that work is happening (skeleton or spinner) and keep the layout stable so nothing jumps when data arrives. Block repeat taps on in-flight actions.
- Empty — say why it's empty and what to do next ("No sales yet — record your first sale"), never just a blank area.
- Error — say what went wrong in plain words and offer a way forward (Retry). Never blame the user; never show a raw error code.
- Offline — keep the app usable; tell the user their work is safe and will sync. Connectivity should never feel like a dead end.
- Success — confirm the action completed ("Saved") so the user knows the loop closed — especially after recording a sale.
When NOT to
- ❌ Don't leave a state unhandled — a blank screen reads as "broken".
- ❌ Don't surface technical error text (codes, stack traces) to the user.
- ❌ Don't let a slow network look like a frozen app — always show loading.
What user problem this solves
Confidence and recovery. DayTwo users are often offline or on slow connections, and a first-timer can't tell the difference between "loading" and "broken". Designing every state — and saying what to do next — keeps the user oriented and in control instead of stuck.
Design the edge states before engineering
Each component and screen should state which states it handles and how. See the full Edge-state checklist for the states to check before a screen is "done".