Loading, Empty, Success, and Error States
Can the intended user understand the next action and recover when the journey is interrupted? Design every material state alongside the ideal populated state and give the user a sensible next action.
What You Will Be Able to Decide
- Explain loading, empty, success, and error states in product and business terms.
- Apply this decision: Design every material state alongside the ideal populated state and give the user a sensible next action.
- Recognise this material risk: a blank or frozen-looking interface causes users to repeat actions or abandon the workflow.
- Use this review: Walk through one client approval on a phone with a missing file, a validation error, and a successful submission.
A founder is reviewing an interface before development effort makes its structure expensive to change. This lesson gives you a concrete question to take into a build brief, proposal review, or product decision.
Can the intended user understand the next action and recover when the journey is interrupted? The course example is A client portal where a small agency collects project approvals; use it to decide what evidence would justify the choice before a builder implements it.
What Does Loading, Empty, Success, and Error States Mean for Your Product?
A founder is reviewing an interface before development effort makes its structure expensive to change.
Use the illustrative service for this course (A client portal where a small agency collects project approvals) to make the choice concrete. Can the intended user understand the next action and recover when the journey is interrupted?
Technical term
Loading, Empty, Success, and Error States
Interface states explain what the system is doing when data is pending, absent, completed, or unavailable.
How Should a Founder Use Loading, Empty, Success, and Error States?
For a client portal where a small agency collects project approvals, ask what would happen if a blank or frozen-looking interface causes users to repeat actions or abandon the workflow.
For this decision, the useful standard is that a representative user can understand the next action and recover when the interface changes state.
- Decision: Design every material state alongside the ideal populated state and give the user a sensible next action.
- Evidence to request: show that a representative user can understand the next action and recover when the interface changes state.
- Owner: name who will respond if a blank or frozen-looking interface causes users to repeat actions or abandon the workflow.
- Record the result in the user flow, wireframes, and interface review.
- Practical review: Walk through one client approval on a phone with a missing file, a validation error, and a successful submission.
How Do You Choose an Approach to Loading, Empty, Success, and Error States?
Can the intended user understand the next action and recover when the journey is interrupted? Design every material state alongside the ideal populated state and give the user a sensible next action.
The risk is that a blank or frozen-looking interface causes users to repeat actions or abandon the workflow. Compare a simpler option with the proposed one, including who will operate either choice.
- Describe the user or business outcome that must be protected.
- Identify the most credible failure and its consequence.
- Compare the simplest adequate approach with one realistic alternative.
- Set a review point for when the decision may need to change.
What Evidence Should You Accept for Loading, Empty, Success, and Error States?
What Warning Signs Should You Look For?
- The proposal does not address this risk: a blank or frozen-looking interface causes users to repeat actions or abandon the workflow.
- Nobody can show whether a representative user can understand the next action and recover when the interface changes state.
- The decision has no named owner or review point.
What Should You Ask a Consultant?
- What changes for the user if we choose this approach to loading, empty, success, and error states?
- How have we reduced or accepted this risk: a blank or frozen-looking interface causes users to repeat actions or abandon the workflow.
- Can you demonstrate that a representative user can understand the next action and recover when the interface changes state?
- Who owns the result, and when will we reconsider it?
Key takeaway
Key Takeaway
Design every material state alongside the ideal populated state and give the user a sensible next action. Ask for evidence against the specific risk: a blank or frozen-looking interface causes users to repeat actions or abandon the workflow.