A useful UI handoff explains what people see and can do before data arrives, after it arrives and when an action cannot finish. If developers receive only a screen filled with ideal data, they must invent waiting messages, recovery paths and retry behavior. Those decisions may be technically plausible while conflicting with product expectations or confusing customers.
You do not need dozens of standalone drawings for every screen. You need a state register connecting cause, presentation, available action and next transition. Shared states can be reused. Missing data, however, must not automatically mean “no results”, and partial completion must not look like complete success.
Start with events, not colors
For each interaction, ask what initiated it, which data is available, whether the system actually knows the outcome and what the safe next action is. Then specify wording, position and appearance. This prevents success messages preceding confirmation or actions appearing for people who cannot use them.
For form feedback, WAI describes notifying users of success and errors and helping them correct mistakes. WAI Forms Tutorial. Persistence and retry details still require product and engineering agreement; an alert color or general design reference cannot settle them.
Within User Interface Design, ask for states that change a user’s decision. Where the same behavior appears across journeys, Design Systems can organise the shared pattern instead of scattering copies across files.
Worked hypothetical: a customer table and bulk action
Imagine an administration interface with customer search and bulk classification changes. This is an illustrative scenario, not a system built by LAB. An employee opens the table, searches for a name and selects three records for a new classification.
Before data arrives, the interface displays a waiting state that cannot be confused with an empty customer database. A successful response containing no customers produces an appropriate first-use state for that employee’s permissions. Existing data with no matches for a filter produces a different message and a way to adjust the filter. Offering “add a customer” in the latter situation could encourage duplicate records.
If the request fails, the interface must not say that the list is empty. Decide whether the last known data stays visible with a clear qualification or is temporarily removed. That depends on the consequences of using stale information and whether its age is known. If access is denied, “try again” should not be the only proposed solution; the next step should follow the system owner’s approved access-request or return path.
Now suppose the bulk operation updates two records but fails for the third. “Updated successfully” is insufficient. The design identifies the unchanged record, explains the available reason and specifies whether a retry applies only to that item. Engineering confirms how repeated execution is prevented or handled before the copy is approved. A retry button does not prove that repetition is safe.
The specification also distinguishes a known failure from an unknown outcome. A disconnected response may leave the interface unable to tell whether processing finished. The team must define a safe status-checking path rather than invent a success or failure merely to dismiss the dialog.
A small matrix prevents substantial ambiguity
| State | Evidence that selects it | Decision to settle |
|---|---|---|
| Initial loading | Request in progress, no displayed data | Which actions remain available? |
| No data | Successful empty response | Is there a permitted first-use action? |
| No results | Filter matches no records | How is the filter changed or cleared? |
| Request failure | Documented failure response | What remains visible and how does retry work? |
| Insufficient permission | Known access refusal | What approved next step is available? |
| Partial success | Different outcomes across selected items | How are unfinished items identified? |
For each row, add Arabic and English copy, the component, relevant focus behavior, the source of error information and the next state. If the cause is unknown, honestly describe the incomplete action instead of asserting that the person’s internet connection is weak.
This register is also a scope control. An additional outcome can be reviewed as a change to an existing state model rather than becoming an unexplained new screen. Conversely, a genuinely different business consequence should not be hidden under a generic component merely to preserve a screen count.
Accept the handoff through a shared walkthrough
Bring design, engineering and the product representative into one review. Walk through agreed test data rather than presenting images sequentially. The engineer should identify the conditions selecting each state, the tester should know how to reproduce it and the product owner should approve the message’s meaning.
Practical acceptance criteria include: failure never appears as confirmed success; retained inputs are specified; disabled actions make sense in context; recovery from error to success is documented; and partial success identifies outstanding work. Use realistic English and longer Arabic messages so content sizing is not postponed until release.
App Development implements the rules. Software Quality Assurance turns the agreed states into repeatable checks and actionable defects. Keeping those responsibilities explicit prevents approval of a design file from becoming evidence that a server or integration works.
Avoid completeness theatre
Do not collapse every failure into “something went wrong”, or expose raw technical server messages without review. A mockup covering only the successful path is not a complete state handoff. Equally, do not add impossible states merely to increase the deliverable count. Validate the product logic. The value is reduced ambiguity, not more artboards.
Frequently asked questions
Must every state be drawn for every screen?
Not if the shared rule and component are unambiguous. Draw consequential differences and link each screen to the correct specification so implementation does not depend on guesswork.
Who writes error messages?
Design or content proposes the wording, engineering confirms the technical condition and the product owner approves meaning and next action. Sensitive situations may need the client’s relevant specialist.
Is a temporary notification sufficient?
It depends on what someone must understand or correct. If the information disappears before they can act, persistent feedback or a retrievable result may be more appropriate.
What if the system cannot tell whether a request succeeded?
Specify an explicit uncertain state and a safe verification path approved by engineering. Do not fabricate success or encourage an unexamined repeat submission.
Start with one widely reused or consequential component. A complete state matrix for it provides a practical foundation for estimating the remaining handoff scope.
Source
- W3C WAI: Forms Tutorial, reviewed 26 October 2026.
