Make a state inventory
For each primary action, list what the visitor sees before, during and after it. A form needs editable fields, pending submission, server rejection, temporary service failure and confirmed acceptance. A filter needs selected, cleared and no-result states. A gallery needs a meaningful initial image, navigation boundaries and focus return. This inventory is more useful to engineering than a single high-fidelity image because it describes how the interface behaves over time.
Preserve the user’s effort
A failed request should not erase a carefully written brief. Keep the fields editable, show the recovery beside the failure and avoid forcing people to reconstruct context. A multi-step form should allow backward navigation without losing answers. If answers are stored locally, disclose the storage, bound its lifetime and provide a clear deletion action. Do not store more personal information than the workflow needs. Persistence is a design decision with a data responsibility.
Say only what the system knows
A client timer cannot prove delivery. Success should follow a real server response, and the copy should reflect the level of confirmation available. “Accepted by the mail server” differs from “Read by our team”. If credentials are missing, offer a direct contact instead of displaying a simulated success. Similarly, an AI demo should disclose deterministic sample answers. Accurate state language prevents the interface from making claims its architecture cannot support.
Review with keyboard and enlarged text
A state is incomplete if it can only be discovered by a mouse. Move focus intentionally when opening a dialog, return it when closing, announce important asynchronous results and keep visible focus indicators. Test with enlarged text and longer translations: a single-line button in English may need two lines in Latvian. Good component behavior connects design intent to everyday access, rather than adding accessibility at the end.