Write error messages that help people recover

What this means for your practice

Explain the immediate issue in plain language and offer an action the person can actually take. Avoid implying certainty about a cause the system has not established.

A practical example

For example, an email field can explain how to correct the address, while a sending failure needs to say whether the enquiry was received and how to proceed. Those are different situations. Ask your supplier to demonstrate both with fictional details and ask reception to confirm any contact advice. Avoid encouraging repeated submission if the outcome is uncertain. A good message restores the person's understanding of the task, rather than using a cheerful apology that leaves them pressing the same button again.

Keep the recovery action close to the error itself. A message that says to contact reception should provide the relevant route, rather than expect people to search the website while unsure whether their request was received. Useful wording and useful placement need to work together.

Make the design useful in everyday work

Write the message around what is known and what the person can do now. A failed submission may have an uncertain cause, so avoid blaming an incorrect detail unless the system has actually identified it. Ask the supplier to show the message beside the relevant control and demonstrate the recovery route. Include the case where repeating the action could create a duplicate request. Reception should verify any alternative contact advice and the wording about what has or has not been received. The message should reduce uncertainty at that particular moment rather than offer a generic apology with no usable next step.

How to check the result

Measure errors that lead to repeated unsuccessful attempts.