Design the state that appears when the normal journey stops

A technician books a piece of equipment for tomorrow. After selecting Save, the connection drops. The page returns to an empty form. Has the booking failed, or has the service saved it and lost the response?

The interface has discarded the distinction the technician needs. Selecting Save again might create a duplicate booking, while leaving the page might lose unfinished work. A useful UI-state inventory describes what the service knows, what the person sees and which actions are safe in that state.

Name the evidence behind each state

Start with one task rather than a library of generic error illustrations. In this fictional equipment-booking service, the task is to reserve an available item for an authorized user and obtain a reference that operations can find.

An empty state should follow evidence of an empty result. A failed query cannot truthfully establish that the user has no bookings. Similarly, a green notification cannot establish a successful save unless it is driven by the required service evidence.

Preserve the user's work without promising a reservation

The technician has entered dates, an item and a collection point. Where the security and retention policy permits it, preserve that unfinished input through a recoverable failure. Explain whether it is merely a local draft or a submitted request whose outcome is being checked.

Those two cases need different actions. A local draft can be edited before submission. An unresolved submitted request needs its original operation identified before another attempt is allowed. The product and engineering teams should agree the state contract; the interface should not infer business success from a completed animation.

If availability changed, show the conflict without silently replacing the selected item. If the user's role changed, do not offer a repeat action that bypasses the permission check. Retaining a draft also does not authorize retaining sensitive information on a shared device indefinitely.

Make the update perceivable

W3C's explanation of WCAG 2.2 status messages covers conveying certain updates to assistive technology without moving focus or changing context. Its error-identification guidance addresses describing detected input errors in text. These are specific considerations, not evidence that the whole booking service conforms to WCAG. W3C: status messages W3C: error identification

For this design, do not rely on a red border to explain an invalid return date. State the problem next to the relevant control and connect the error to it programmatically. Decide how a save status is announced without repeatedly interrupting the user or moving the keyboard focus for every background poll.

The exact interaction needs testing in the implemented interface, including keyboard and screen-reader use. A design file that names an accessible state is a requirement to verify, not a completed accessibility result.

Walk the inventory with the people who handle exceptions

Ask support what happens when a caller reports “the form disappeared.” Can the operator locate the original request? Can they distinguish an invalid draft from a booking that succeeded? Does the customer message give a useful reference without exposing internal or sensitive data?

Use the journey-mapping guide for the wider waits and handoffs around the screen. Keep this UI record narrower: state evidence, message, permitted action, recovery destination and owning team. A loading indicator does not need to become a service blueprint.

Test transitions as well as screenshots. Interrupt the network after the service accepts a save. Return to the tab after availability changes. Remove permission before confirmation. Use a successful empty response and a failed query as separate cases. Check that the system preserves the intended distinctions all the way to the user's next action.

When the technician comes back online, the interface should recover the existing booking or explain what remains unresolved. It should not make the person guess whether another click creates another reservation.

The equipment-booking scenario and state inventory are proposed examples. W3C guidance was checked on 25 October 2026.