How to Write Error Messages People Can Actually Use

An error message is part of the product

People usually meet an error message when something they expected has already gone wrong. They may be rushed, worried about losing work or unsure whether they caused the problem. At that moment, polished brand language matters less than a clear path forward. A useful message answers three questions in a sensible order: what happened, what remains safe, and what the person can do next. “Something went wrong” answers none of them. It describes the product team’s uncertainty and transfers that uncertainty to the user. Even when the technical cause is unknown, the interface can still say which action failed and offer a realistic next step.

Name the failed action, not the user

Start with the action the system could not complete. “We couldn’t save this draft” is more precise and less accusatory than “Invalid submission.” Avoid telling people that they “failed” to enter data correctly. If a field needs attention, identify the field and the requirement: “Enter a phone number with 10 digits.” Keep the visible message free of internal status codes, database terms and stack traces. Those details may belong in logs or an expandable support panel, but they do not help most people recover. Clear wording does not mean pretending the problem is simple. It means placing technical detail where it can serve the right reader.

Say what happened to the person’s work

Uncertainty about lost work is often more stressful than the error itself. If the draft is still stored locally, say so. If a payment was not charged, confirm it. If you cannot know whether an action completed, do not reassure people without evidence; tell them how to check before trying again. This is especially important for actions that create duplicates, send messages or move money. “Try again” can be dangerous advice when the first request may still be processing. Good error copy reflects the actual state of the system. The writer therefore needs a short conversation with engineering or support, not just a list of screens to fill with friendlier words.

Offer one specific next step

A strong message ends with an action that is possible now. That might be “Check your connection and try once more,” “Use a file smaller than 10 MB,” or “Copy your text before refreshing the page.” If there are two genuinely different routes, present them as labeled actions rather than hiding both inside a paragraph. Avoid empty instructions such as “Contact support” unless the link carries useful context into the support request. When waiting is the only option, give an honest time range and explain whether the page will update automatically. Specific guidance reduces repeated attempts, support tickets and the quiet loss of trust that follows a dead end.

Test the message in the broken state

Review error copy where it will actually appear, not only in a spreadsheet. A sentence that looks concise in a content table may wrap badly beside a narrow form, repeat a heading or disappear below the keyboard on a phone. Trigger the error and read the whole screen aloud. Check that the message is associated with the relevant field for assistive technology and that color is not the only signal. Search the product for variations of common phrases so similar failures use consistent terms. Then ask someone who did not write the message what they would do next. If their answer differs from the intended recovery path, the copy is not ready. The best error message is not clever; it is the shortest honest bridge from interruption to progress.

After release, compare the wording with real support questions. If people repeatedly ask whether their work was saved, the message has left a critical fact unstated. Updating the copy in response is maintenance, not failure: broken states change as the product changes.