The completeness verification system. Every interactive system has states. Missing states cause bugs, confusion, and lost trust. This checklist ensures every meaningful state is accounted for before any work is considered complete. Use it. Do not skip it.
- Default — What does the normal state look like? This is the baseline. Everything else is deviation from this.
- Hover — What changes when mouse is over it? This is the first interaction. Do not ignore it.
- Focus — How is keyboard focus indicated? Accessibility is not optional. If you ignore focus, you ignore keyboard users.
- Active/Pressed — What shows when actively clicking? The moment of interaction. It must feel responsive.
- Disabled — How does it appear when unusable? Disabled is not invisible. It is a state that must be designed.
- Loading — How is processing communicated? Not "loading..." as text—that is failure. What does the user see while they wait?
- Empty — What displays when no data exists? Empty is not "nothing." Empty is a state that requires design.
- Error — What shows when something fails? Error states are often the only state users see when things go wrong. Design them like they matter.
- Success — What confirms completion? The user needs to know it worked. Design the success state like it is the goal—because it is.
- Selected — How is the chosen state shown? Selection is not implied—it is explicit. Make it obvious.
- No data — Clean empty state with action. Not "no data" as text—that is failure. Show a meaningful empty state that prompts action.
- Partial data — Loading or incomplete content. The in-between state. What shows when data is arriving but not complete?
- Full data — Normal populated state. The ideal state. Does it work as expected?
- Stale data — Outdated but still displayed. How does the system handle old data? Does it warn? Does it refresh?
- Corrupted data — How is broken data handled? Not "error"—specific handling. What does the user see? What can they do?
- Pristine — Empty form, no interaction. The state before the user does anything. Does it look ready to be filled?
- Valid — All inputs correct. The desired state. What feedback confirms correctness?
- Invalid — Errors present and shown. Not "invalid input"—specific errors. What is wrong? How is it fixed?
- Submitting — Processing in progress. What prevents double-submit? What shows progress?
- Submitted — Confirmation of success. Not "success" as text—what specifically happened? What happens next?
- Failed — Submission error handling. What went wrong? What can the user do? Can they retry?
- Initial — Before any request. The starting point. Is the initial state designed?
- Loading — Request in flight. The waiting state. Not a spinner—that is the minimum. What else?
- Success — Data received successfully. The ideal state. Does it display correctly?
- Error — Request failed. The failure state. What went wrong? What can the user do?
- Timeout — Request took too long. The specific failure. How is it handled? Does it retry?
- Offline — No connection available. The disconnected state. What can the user do? Can they work offline?
- Allowed — Full access permitted. The expected state. Does it work as expected?
- Denied — Access explicitly refused. The barrier state. What does the user see? What can they do?
- Pending — Authorization in progress. The waiting state. How is it communicated?
- Restricted — Partial access only. The limited state. What can they access? What is blocked?
- Very long text — How does it wrap? How does it truncate? Does it break layout?
- Very short text — What is the minimum width? Does it look broken?
- Zero — How is the number zero displayed? Is it "0" or "—" or nothing?
- Negative numbers — Are they handled? What do they mean in this context?
- Maximum values — What happens at limits? Does it cap? Does it warn?
- Rapid clicks — How is double-submit prevented? Disabled button? Loading state? Redirect?
- Browser back — Does it work correctly? Does it go back in your app or out of your app?
- Page refresh — Does state persist or reset? What is lost? What should persist?
For each state, verify:
- Can you reproduce it? If you cannot, you have not designed it.
- Is there visual design for it? If it looks the same as other states, it is not designed.
- Is there interaction design for it? If it feels the same as other states, it is not designed.
- Is there error handling for it? If it fails silently, it is not handled.
- Is there documentation for it? If you cannot explain it, you have not planned it.
If any answer is "no," the state is not covered. Fix it.
A user should never wonder "why is this like this?" Any state that confuses is a state that failed. Cover every state before you ship. There is no excuse for missing states.