Edge Cases and Product States
Design the moments when the happy path is unavailable. · Execution & Communication · Lesson 60 · 3 min
Edge Cases and Product States · 3 min
Situation
The main screen is beautiful and empty.
A new customer opens an analytics page before any events have arrived. The design shows charts filled with realistic data, but the implemented page displays blank boxes.
An empty state is a normal product state. It deserves a clear explanation and a useful next action rather than looking like a broken page.
Mental model
Walk through the state transitions.
Consider empty, loading, success, error, permission denied, offline, duplicate action, and partial completion. Ask how the user reaches each state and what they can do next.
Not every feature needs every state, but every reachable state needs intentional behavior. Think about transitions, not only isolated screenshots.
Example
A bulk update can partly succeed.
A user changes 100 records. Ninety update and ten fail validation. Showing “Update failed” hides successful changes; showing “Done” hides failures.
Report both outcomes, identify the affected records, preserve the user's input, and provide a safe retry for the failed subset. Define whether the operation is all-or-nothing before building it.
Failure case
A loading spinner becomes a permanent state.
If the request times out without a recovery path, users may refresh, submit again, or abandon work. A duplicate submission can create a second action.
Clarify cancellation, retry safety, and how the interface checks the confirmed server state. A disabled button alone does not prevent all duplicates.
PM question
What does the user know at this moment?
For permission denied, explain the next step without exposing protected data. For offline work, distinguish local changes from synchronized changes. For errors, preserve recoverable effort.
Review states with engineering and design using concrete cases. Ask support which confusing states already create the most tickets.
Remember this
The edges are part of the main experience.
Design how the product explains uncertainty, preserves work, and returns users to a useful path. Reliability is often felt most strongly during recovery.