Design forms that help people recover from errors

Prevent the avoidable mistakes first

Before writing a single error message, ask whether the form made the requirement clear. A field labelled “Reference” might be obvious inside the company and meaningless to a customer. A required format that’s only revealed after submission creates work nobody needed to do.

Use labels that describe exactly what you’re asking for. Put essential instructions where people need them, and mark optional fields clearly. Only ask for what the task genuinely needs. Removing a question nobody needs to answer beats improving its validation every time.

Validate at the right moment

Not every check should happen while someone types. An email address is supposed to look incomplete halfway through typing it. An error that pops up too early is just a distraction. Check once the person has given you enough to judge.

It also helps to separate three kinds of problem. A format issue (“Enter a date like 14/10/2026”), a business rule (“That date is outside the booking window”) and a system failure (the service is unavailable) are different things. The last one isn’t the user’s fault, and the message shouldn’t suggest it is.

Make errors easy to find

An error next to a field explains the local problem. On a longer form, a summary at the top helps people find everything that needs fixing. It should link straight to each field and use the same wording.

The GOV.UK error summary is the best public example we know of this pattern, and W3C’s validation tutorial covers the accessibility side. Both are worth a read. Either way, test your version in the real form, with a keyboard and a screen reader, not just in a static mock-up.

Keep people’s work safe

When a submission fails, keep everything that was valid unless there’s a genuine security reason not to. If something has to be re-entered, say what and why. For longer tasks, think about saving progress and how people get back to it.

Picture a supplier registration form where one attachment is too big. Clearing the whole form turns a small fix into a twenty-minute job. A much better response names the file, states the actual size limit and keeps every other answer. If the upload can be retried on its own, make that obvious.

Plan for uncertain outcomes

Sometimes a request times out after the server has already received it. If you just ask the user to submit again, you might create a duplicate. Work with engineering to understand whether the system can check for an existing submission, retry safely, or at least give a reference number for support.

On broadband self-service journeys for a major UK provider, a lot of the design effort went into exactly these branches: checks that failed, setups that were only half complete, equipment that hadn’t arrived. Those were the moments customers most needed help, so they got as much design attention as the main path.

Review the full set:

• Missing or invalid information.
• A rule that blocks the requested action.
• An expired session.
• A failed upload or a dropped connection.
• A slow response after submitting.
• A successful submission and what happens next.

Skip success messages that just say “Done”. Tell people what was completed and whether anything’s still outstanding. For actions with real consequences, a check-your-answers step before committing is worth the extra screen.

Test recovery with real tasks

A form can look fine in a design review and still be hard to recover from with a keyboard or assistive technology. Test focus order, how errors are announced and whether summary links land in the right place. Include people with relevant access needs if your research scope allows it.

Have a look at the broadband self-service case for how this played out across web and mobile. Complex Workflow Design brings forms, rules and recovery states together into one journey.