A UI state inventory lists how each important view behaves during loading, empty results, validation, restricted access, failure and completion. Use it to scope design and implementation together. Counting only the screens shown in a polished prototype misses work users will encounter during ordinary interruptions and corrections.
Let’s plan your UI state coverage.
Bring your workflow and the decisions you need to make. We’ll help you clarify requirements, review the trade-offs and define a practical next step.
Inventory by journey and consequence
Start with a complete task, then list the views and states it crosses. Avoid creating every theoretical combination as a separate design file. Prioritise states that change the user's decision, available action or understanding of the outcome.
For a hypothetical service form, the initial screen, saved draft and rejected submission may share a layout but require different content and behaviour. Those differences need an agreed design treatment.
Use a state worksheet
| State family | Question to answer | Design evidence |
|---|---|---|
| Initial and empty | What can users do before data exists? | Useful instruction and permitted next action |
| Loading | What is waiting and what remains usable? | Stable layout and honest status |
| Validation | Which input needs correction? | Label, reason and recovery |
| Permission | Is the action unavailable or the record restricted? | Appropriate explanation and boundary |
| Failure | Did the operation fail or become uncertain? | Preserved work and safe next step |
| Completion | What has actually happened? | Confirmed outcome and reference |
| Changed context | What if the record changes elsewhere? | Refresh or conflict treatment |
Link each state to a requirement or acceptance case. A collection of attractive error illustrations is not the same as a recovery specification.
Coordinate design and engineering decisions
Identify which states depend on server capabilities. An undo design requires a real reversal mechanism; a percentage progress bar requires a measurable basis. Resolve those dependencies before presenting the interaction as agreed scope.
Record common patterns in the design system while preserving task-specific meaning. Shared components can standardise layout, but the explanation for a declined approval should not be copied from a failed file upload.
Use the inventory for estimation and review
Ask suppliers to state which state families and journeys are included. Review the implemented states in demonstrations instead of accepting the happy path as evidence that the view is complete.
When scope changes, update affected states and acceptance cases. A new asynchronous integration may introduce pending and uncertain outcomes even if it adds no visible screen to the original design count.
State-inventory questions
Does every state need a separate full-fidelity mockup?
No. Use the level of detail needed to communicate behaviour and remove ambiguity, with explicit references to shared patterns.
Can testing invent missing states later?
Testing can expose gaps, but discovering recovery behaviour late can create avoidable rework and inconsistent product decisions.
Use the design handover checklist and discuss the inventory with Drema's UI/UX team.
