Design the moment something goes wrong

01The screen after the mistake is part of the product

Imagine completing a service request on your phone. You submit it and the page says “Invalid input.” The form has cleared. You do not know which answer failed or whether the business received anything. The interface has transferred its uncertainty to you.

This is an illustrative scenario, not a reported client result. It points to a concrete design question: can a person understand the problem, preserve their work and recover without help? The default design review often concentrates on an empty form and a successful submission. Both are incomplete views of the experience.

02Make the field understandable before validating it

Give each field a persistent, programmatically associated label. Put essential instructions where a person needs them. If a field is optional, say so; if it needs a particular format, explain it before the error. A placeholder can demonstrate an example, but it disappears during typing and should not carry the field’s only label.

W3C’s forms guidance covers labels, instructions, validation and feedback. Those are practical starting points, not a claim that this short exercise certifies accessibility. Different assistive technologies and real user needs require proper testing.

Ask why each piece of information is needed at this stage. Removing an unnecessary field may be better than designing an elaborate explanation for it. Keep information that is genuinely required to route or fulfill the request.

03Write an error that enables a next action

In the imagined service form, “Invalid input” becomes a field-specific instruction such as “Enter an email address in the form name@example.com.” Show the message near the field, associate it with that field for assistive technology and explain the problem in text rather than color alone.

For multiple errors, an accessible summary can help people find what needs attention. Retain appropriate non-sensitive answers so they do not have to start again. Do not automatically preserve passwords, payment details or sensitive notes without considering the security and privacy implications.

The response should accurately describe the system’s state. If the server failed after submission, do not display a success message. If the system cannot determine whether the request arrived, explain the uncertainty and provide a safe recovery route rather than encouraging uncontrolled repeat submissions.

04Review four versions of the same task

Create an empty state, an invalid state, a pending state and a confirmed state. Use realistic but invented data. Have a reviewer complete the task with a keyboard, on a narrow screen, and with the accessibility tools appropriate to the product. Check that focus remains understandable, errors can be found and controls have meaningful names.

Observe before coaching. If somebody keeps pressing Submit during a delay, investigate whether the interface communicates progress. If they assume a request is booked when it is only received, the language and feedback need correction.

A short internal review can reveal defects. It cannot establish that an interface is accessible to everyone or that customers will complete more requests. Include people with relevant access needs in the wider evaluation.

05Keep useful friction

Not every additional step is a defect. Reviewing a consequential order, confirming a destructive action or checking a critical detail can protect the user. The design decision is whether a step prevents a meaningful error or merely makes the business’s administration easier.

Record the specific defect, the changed interaction and the recovery you observed. That is stronger evidence of UI/UX quality than a prettier screenshot of the same happy path.