How to Edit AI-Generated Error Messages for a Clear Next Step

“Something went wrong. Your work is safe. Try again.” That message contains three claims: an operation failed, the work was preserved, and repeating the action is appropriate. An AI draft can supply all three without knowing whether any of them is true.

To edit AI-generated error messages, check the actual failure state before polishing the words. Establish what the system knows, what happened to the user's work, and which action is available. Then write a short message that identifies the problem and gives a verified next step. If the outcome is unknown, preserve that uncertainty instead of inventing reassurance.

Start with a state brief for each message

An error string needs evidence from the product or process owner. A screenshot of the message alone may not show what triggered it or whether the operation completed elsewhere. Ask for a short brief with these fields:

Keep “visible in the current form” separate from “saved to the account.” They describe different states. Likewise, a file rejected before upload is different from an upload whose result was not received. A single friendly sentence should not flatten these differences.

Microsoft's error-message guidelines recommend messages specific to known causes and language suited to the audience. Apply that principle to the brief: do not make a more specific claim than the system can support. For unresolved operational facts, use the separate AI-text fact-checking workflow to record what needs confirmation.

Decide whether the user can correct the problem

A missing field, a service outage, and an uncertain submission outcome need different responses. Classify the condition before asking AI for alternatives.

The input needs correction

Name the relevant field and the requirement the user can satisfy. “Invalid file” leaves the reader guessing; a verified file-type rule can support a message naming the accepted formats. Do not invent a size limit or format example because it sounds helpful.

The GOV.UK error-message component guidance distinguishes problems with user input from service problems and recommends specific, consistent wording. Its advice also makes clear that preserving entered answers is a product behavior, not something an editor can accomplish by saying the answers are preserved.

The service cannot complete the action

Tell the reader which task is unavailable and what useful route exists. Do not ask them to correct a field when their input is not the problem. The GOV.UK service-problem pattern includes information about what happened to entered answers and relevant contact options. Those details must come from the real service; a sample message is not permission to promise that another product saves work.

The result is unknown

Sometimes the interface cannot confirm whether an operation finished. The copy must not turn “unconfirmed” into “failed.” Ask the product owner how the user can check the result before repeating an action that could create a duplicate. If no safe route is established, that is an unresolved product question to settle before approving the message.

Worked example: four states in a fictional upload form

The following is invented teaching material, not a Humanizer.help feature description, customer story, or usability test.

Assume the owner of a fictional community archive supplies these facts:

• The Document field accepts PDF files of 8 MB or less.
• A rejected file is not uploaded. The other form fields remain visible while the user stays on the page; the service does not save them as a draft.
• Choose file lets the user select a replacement.
• If an upload response is lost, completion is unknown. View uploads opens a list that the owner has confirmed shows every completed upload. The user should check it before uploading again.
• During a service outage, uploads are unavailable. The cause and recovery time are unknown. A working Contact the archive team link is available.

These facts define the example. A real editor must obtain equivalent evidence for their own service.

Compare the draft with the supplied state

The first draft invents file damage. The second invents a percentage reduction that may not make the file small enough. The third assumes failure where the outcome is unknown. The fourth invents a cause, saved-work promise, and recovery time. None of those problems is repaired by making the tone warmer.

For the first two states, the surrounding form can also say: “Your other answers are still in this form. They are not saved if you leave this page.” That statement follows the fictional brief. It would be wrong to shorten it to “Your work is saved.”

Review the action as well as the sentence

Check that Choose file, View uploads, and Contact the archive team are real, available controls with the stated behavior. In the uncertain-outcome state, the list is useful only because this example explicitly says it includes every completed upload. If a real list updates slowly or omits some results, the owner must specify another safe check; the editor cannot assume an empty list proves failure.

The Google Chat guide to actionable error messages organizes useful messages around the problem, a way forward, and access to help. Use that as a review question, not a demand to squeeze three sentences into every small field error. A simple missing-value message may need only one precise correction.

Keep unknown facts out of reassuring copy

AI-generated messages often add a cause to make the explanation feel complete. “Your connection dropped” is only appropriate if that is established. If the system knows only that it did not receive a result, say that instead. Atlassian's error-message guidance explicitly advises against making up an unknown reason.

Review reassuring phrases with the same care as technical claims:

• “Nothing was lost.” Which information is preserved, where, and for how long?
• “You haven't been charged.” Has the relevant transaction state actually been confirmed?
• “Try again.” Is retry appropriate for this condition, and can it repeat a completed action?
• “We'll fix it shortly.” Is there an authorized time commitment?
• “Contact support.” Can the intended user reach a specific, working support route?

These are questions for the owner. The editor's task is to remove unsupported statements and obtain the missing facts, not diagnose infrastructure from the text. For sensitive account or transaction states, let the responsible team define what can safely be disclosed.

Make the wording calm and specific

Once the state is correct, remove blame, jokes, and language the audience does not need. Replace “You entered bad data” with the actual field requirement. Keep an error code available when it helps support investigate, but do not make the reader decode it to learn the next action.

Use the product's established names consistently. A message that says “Open history” beside a control called View uploads adds an unnecessary matching task. Avoid replacing exact interface labels merely to make the sentence sound more conversational.

Tone conventions vary. A brief apology can fit a serious service failure; a routine missing-field message usually needs the correction more than an apology. Follow the relevant product style and the consequence for the reader. There is no universal requirement to add “please,” “sorry,” or an exclamation mark.

Approve the rendered state, not just a spreadsheet row

A correct string still needs to appear at the right moment and remain connected to the relevant control. W3C's error-identification explanation calls for automatically detected input errors to be identified and described in text. Its error-suggestion guidance addresses known corrections, with an exception when disclosure would undermine security or the content's purpose. These are separate questions from whether the prose sounds natural.

For an authorized review environment, ask the implementation owner to demonstrate each trigger and check:

1. The message matches the actual condition, including any uncertain outcome.
2. The named field and available action are identifiable.
3. Statements about preserved input match what happens when the user stays, leaves, or returns.
4. A correction or help link leads to the intended result.
5. Repeated versions of the same error do not contradict each other.
6. The message is exposed appropriately to assistive technology and keyboard users.

The W3C forms-notification tutorial provides implementation examples for overall and inline feedback. An editor should hand off those checks rather than claim that rewritten copy certifies accessibility. For the surrounding help article, the screen reader navigation editing guide covers headings and links.

Save the approved wording beside its trigger, evidence, and unresolved questions. If you only reviewed the copy, record that boundary. Mark the rendered behavior verified only after someone actually checks it.

FAQs

Should every error message explain its cause?

Only when the cause is known and useful to the reader. An accurate statement of the problem and a verified next action is better than a plausible diagnosis.

Is “try again” always a bad instruction?

No. It can be useful when retry is the confirmed recovery action. It is incomplete when the user must change something first, and inappropriate when the previous action's outcome needs checking.

Can AI generate the final message from an error code?

An error code alone may not establish the user's outcome, retained input, or available controls. Supply a verified state brief, review the proposed text, and check the implemented state before approving it.