A screen with realistic content is easy to review. A screen with no results, a pending action, or a partial failure is where the product often reveals its unfinished decisions.
These states are part of the feature. They tell people what happened, what is still happening, and what they can do next. Designing them early also makes handoff more precise because engineering does not need to invent the behavior around the approved mockup.
Start with a state inventory
Take one feature and list the situations that change its meaning. For a reference search, the inventory could include an initial blank query, a request in progress, useful results, no results, a failed request, and results that become outdated after a filter changes.
Then add actions inside the results: saving a reference, confirming that it was saved, and recovering when the save fails. A search screen may contain several independent state transitions.
Keep the inventory focused on observable behavior. “Backend failure” is not a complete design state. “The search could not load; the previous results remain visible and the person can retry” is much more useful.
Distinguish empty from unsuccessful
An empty project has no saved references yet. An empty search has no matches for the current query. A failed search does not know whether matches exist. These situations should not share an ambiguous “Nothing here” message.
For a first-use project, explain its purpose and offer the next action: “Save references here to compare them while you work.” For a search with no matches, preserve the query and suggest changing the term or filters. For a failed request, explain that loading failed and offer a retry.
The message should describe the known situation. Avoid suggesting that the person made a mistake when the system simply could not complete the request.
Decide what stays visible during loading
Loading is a design decision about continuity. Should existing content remain visible while a new request runs? Should a button show progress? Can the person leave, cancel, or change the query?
For a filter change, keeping the previous results visible can preserve context, but label the pending update so old results are not mistaken for new ones. For an irreversible action, consider whether the control needs protection against duplicate submissions.
Define the transition when a request arrives out of order. If someone searches for “checkout” and then “settings,” an older checkout response should not replace the newer settings results. This is a behavior requirement worth including in the design notes.
Preserve work when recovery is possible
An error should not erase input unnecessarily. Keep a draft message after a send failure. Preserve a query after a search failure. Retain promotion terms after a partial batch failure so the operator can retry the remaining accounts consistently.
Separate successful work from unfinished work. If seven of ten operations complete, say which seven succeeded and which three need attention. A generic failure message can encourage duplicate work or leave people unsure what changed.
Also decide when a result is safe to describe as complete. Starting a file download is different from confirming that the file was saved. An authorization is different from a completed export. Accurate status language makes the interface more trustworthy.
Research states as complete sequences
When reviewing references in Refcat, keep the trigger, the intermediate state, and the recovery screen together when those examples are available. Search for the task rather than only for the visual treatment of an error.
Annotate missing states explicitly. A reference showing a successful checkout does not tell you how that product handles a timeout. Your team still needs to make that decision.
Hand off a transition table
A small table can make the intended behavior concrete:
| Trigger | Visible state | Available action | Next state |
|---|---|---|---|
| Search submitted | Updating, query preserved | Edit query | Latest results |
| No matches | Empty result explanation | Change query or filters | Updating |
| Request fails | Error, input preserved | Retry | Updating |
| Save succeeds | Saved confirmation | Open project | Project |
Add accessibility expectations such as focus movement and status announcements to the relevant transition. Review these behaviors in a working interface.
The happy path shows what the feature can do. Its other states show whether people can depend on it.