How do I write an error message that tells users what to do next?

Treat the message as a small set of directions, not just an announcement that something failed. A useful pattern is:

1. State what could not be completed.
2. Give the next action the user can take.
3. If that action might not help, offer a reasonable alternative or explain what information to provide when asking for help.

For instance, “Something went wrong” names neither the problem nor a next step. If the issue is a missing required field, a more useful message might be: “We couldn’t save this form. Add a response to the marked field, then select Save.” That tells the user what happened and where to act, without implying they did something foolish.

Describe the state of the task rather than judging the person. Prefer “We couldn’t find an account with those details” to “You entered the wrong details.” The first explains the obstacle without assigning blame; the second can sound accusatory and may not even be accurate.

Keep the opening short, then make the action concrete. “Please try again” is often too vague by itself. If you know what retrying means, say it: “Wait a moment, then select Submit again.” If you do not know a safe or reliable recovery step, do not invent one. Say what the user can do next to get help, using a placeholder for the appropriate support route if needed.

Sure. These are illustrative examples; replace the bracketed details with actions your product actually supports.

1. Missing information

Weak: “Invalid form.” Clearer: “We couldn’t send this form. Add a response to [field name], then select Send.”

1. A file that could not be accepted

Weak: “Upload failed.” Clearer: “We couldn’t upload [file name]. Choose a file in [accepted format], then try again.” Only name a format if you know it is accepted.

1. A save that did not complete

Weak: “Error 104.” Clearer: “Your changes weren’t saved. Try saving again. If the message returns, copy your changes and contact [support route].” Include the copy step only if it is practical in the product.

1. An unavailable item

Weak: “Not found.” Clearer: “We couldn’t find [item name]. Check the name, or return to [relevant list] and choose an available item.”

The examples connect the problem to a next action. Avoid promising that an action will fix the issue unless you know it will.

Be honest about what the message can say. You do not need to guess at a cause. State the outcome and offer the next useful step: “We couldn’t complete this request. Try again later, or contact [support route] and include [reference number, if available].” Use “try again later” only when waiting is a reasonable option for that situation.

If the user needs help, make the handoff specific: say what to include, such as the action they were taking or a displayed reference number, if your product provides one. Do not ask them to share sensitive information in an error message. If there is no suitable self-service action, say so plainly rather than sending them through irrelevant steps.

Use this template:

“We couldn’t [specific task or outcome]. [Specific next action]. If that doesn’t work, [alternative action or support route].”

For example, assuming the product allows another attempt and has a support route: “We couldn’t submit your request. Check the marked fields and select Submit again. If it still doesn’t work, contact [support route] with reference [reference number].” Remove any step that the product cannot actually support.

Before using a message, check it against these questions:

1. Does it name what did not happen in words the user will recognize?
2. Is the next step specific and possible in the current situation?
3. Does it avoid blame, jargon, and unexplained codes?
4. Is there a useful alternative if the first step fails?
5. Have you removed any promise or cause you cannot verify?

A good error message cannot always solve the underlying problem. It can still make the next available action clear.