A polished screen usually shows the application at its easiest moment: the data exists, the connection works and the person has the right permissions. Real use includes many other states, and the interface needs to remain understandable through them.
Begin before the data arrives.
What should a person see while the application is waiting? The interface needs to distinguish an operation in progress from an empty result or a failure. Otherwise someone may repeat an action because the first attempt appears to have disappeared.
Consider what remains usable during that wait. A loading indicator helps explain status, but the application also needs rules for cancelling, navigating away and returning to unfinished work.
Give empty states a purpose.
An empty list can mean a new account, a search with no matches or data the current role cannot access. Those situations need different explanations and next actions.
A useful empty state answers what happened and what the person can do. It should not encourage an action the user lacks permission to perform, or imply that information has been lost when it has not been created yet.
Help people recover from errors.
Validation should explain the specific input that needs attention while preserving useful work. A general error message at the top of a long form can leave someone searching for the problem.
For an unavailable service, explain the practical next step where possible. Do not describe a failed operation as successful, and do not invite a retry without considering whether it could create a duplicate action.
Review states as connected journeys.
Create a state checklist for the main workflow and review it with the people implementing the product. That exposes missing decisions about permissions, connectivity and existing data before they become last-minute guesses.
Keyboard use, small screens and readable labels belong in that review. The goal is not a collection of extra mockups; it is a coherent explanation of how the application behaves in use.
The quality of an application becomes especially visible when the expected path is interrupted.
Questions for the working session.
- Can users distinguish loading, empty and failed states?
- What work should be preserved after an error?
- Does each role have a truthful next action?
- Has the full journey been reviewed on narrow screens and with a keyboard?