Every empty, error and edge
Lesson 21 of 24, level 01Index
The happy path is four screens. The unhappy paths are nineteen, and QA will find them for you in front of the CTO.
The unhappy path is most of the product
Every screen has around eight states, and most specs draw one. The states you do not draw get invented by an engineer under time pressure at 6pm on a Friday.
This is the cheapest quality win available to a product manager. It costs an hour and it removes a category of bug.
A product is a collection of states and transitions, not just a happy-path screenshot. The user needs to understand what is happening when the system is empty, slow, partially successful, or unavailable.
Use your chosen course project throughout. The additional examples below are fictional practice cases; transfer the method to your own evidence.
List state families
For each important object, consider initial, loading, empty, success, partial success, error, and unavailable states. Do not add all of them mechanically; explain which can actually occur in your flow. Distinguish no data yet from no results after filtering, because the useful next action differs.
Connect the user and system views
Specify what the system knows, what the user sees, and what action is safe. A timeout may mean the client does not know the outcome, not that the operation failed. Confirming status before retrying can prevent duplicate work. Ask engineering which outcomes can be verified and which remain uncertain.
Write recovery as behavior
An error message needs a next step when one is possible. Explain whether entered data remains, whether a retry is safe, and how a user can leave and return. Test keyboard focus and status announcements as part of the interaction, not just the visual layout. Decorative animation should never be the only indication of state.
A timeout is not always failure
- Request: Attempt begins
- Unknown: Check the status
- Confirmed: Show the outcome
- Recover: Safe next action
Doing it with AI, and where it breaks
Enumerate failure states with a model, then find the four it missed because they are specific to your product.
It gives you the generic eight. Your product has domain specific ones, like a bank connection that succeeds but returns no transactions, which no generic list contains.
Your AI workbench
Start with your own notes or clearly labelled practice data. Remove private details before sharing. Replace the placeholders, run the prompt in your chosen AI tool, and keep the output beside its source.
Audit this flow and API behavior [paste]. Create a table of system state, user message, available action, data preservation, and accessibility behavior. Include timeout with unknown outcome, partial success, retry, and return visits where applicable. Mark backend assumptions for engineer review.
Before you use the output
- Unknown outcome differs from confirmed failure
- Recovery preserves necessary user work
- State is understandable without animation or color
Stuck? Try this next
Ask AI to generate acceptance scenarios in Given/When/Then form. Run through them against the prototype and implementation contract rather than assuming generated tests describe real capabilities.
Keep a brief AI log: input used, useful output, what you checked, and what you rejected. The decision remains yours.
Build it
A complete states matrix for one screen of your product.
Checkpoint
If you did the build, these take two minutes. If you cannot answer one of them, that is the part to go back to.
Moving on marks this lesson complete. Finish the build first, it is the part that counts.