Write Better Error Messages with AI: UX Copy Examples

To write better error messages with AI, provide the exact failure state, what the system knows and what the user can do next. Ask for wording that identifies the problem and gives an accurate recovery action. Check every proposed message against the implemented behavior before putting it in the product.

An error message is a small operational promise. “Your work is saved” must be true. “Try again” must be a meaningful action. AI can help make the wording clearer, but it should not invent a cause, recovery path or reassurance.

Define the state before the sentence#

Create a short state brief with the trigger, known cause, affected object, available action and whether user input is preserved. Add a character limit only if the actual interface needs one. Describe where the message appears: next to a field, in a banner or in a dialog.

Keep system facts separate from tone preferences. A friendly message that names the wrong cause is less useful than a plain message that accurately explains the next step.

Use before-and-after examples carefully#

For a fictional upload form, “Invalid input” could become “Choose a CSV file,” if CSV is the only supported format. If the application also accepts XLSX, that revision would be wrong. Include the actual accepted formats in the brief.

For a failed save with an unknown cause, avoid “Your internet connection is down” unless the product can establish that. A more accurate message could be “We could not save your changes. Keep this page open and try saving again,” provided that keeping the page open preserves the unsaved work and retry is supported.

These are illustrative drafts. The correct wording depends on what the interface does. Verify the state and recovery before adopting an example.

Copy this microcopy prompt#

Draft error-message options for the following verified state.
Trigger and placement: [details]. Confirmed cause: [known or unknown].
Affected item: [details]. Available recovery: [actions].
Preserved input and irreversible effects: [facts]. Tone and length: [limits].
Return three concise options with a proposed button label where relevant.
Explain which facts each option relies on. Do not blame the user,
invent a cause, promise data is saved or suggest an unsupported action.
Flag missing product facts before writing definitive copy.

Ask for options with different emphasis only when there is a real choice. Do not optimize for cleverness; the reader is trying to recover from a failure, often under time pressure.

Write for recovery and orientation#

Name the relevant field when the message is not visually adjacent to it. Explain a format requirement with a concrete example. If several errors exist, help the user locate and correct them rather than presenting a generic failure banner alone.

Avoid internal codes as the only explanation. A code can remain useful for support if the product provides a readable message beside it. Also avoid vague actions such as “Fix it” when “Choose another file” or “Enter an email address” is the supported next step.

W3C's error suggestion guidance explains the value of helping users correct detected input errors when an appropriate suggestion is known. The implementation must still associate and announce the message correctly.

Keep sensitive states appropriately general#

Some authentication flows intentionally avoid confirming whether an account exists. Do not ask AI to make the wording more specific without checking the product's security requirements. Similarly, a payment failure should not expose sensitive details or promise an outcome the system cannot verify.

The writer's job is to make the approved behavior understandable. When specificity conflicts with a verified product constraint, explain the available next step without inventing additional disclosure.

Review the whole interaction#

Read the message with its field label, instructions and button. If the message says “Try again,” the button should make the retry clear. If the user needs to edit a value, focus and navigation should support that action.

Test long translations and narrow screens. A short English sentence may become longer in another language. Preserve the key meaning when adapting copy instead of shortening until the recovery instruction disappears.

Maintain a state-based message library#

Store each approved message with its state, owner and product rule. Reuse language for the same behavior, but do not force different failures into one generic sentence. Review messages when validation rules or recovery paths change.

Use the content accessibility review to inspect labels and instructions. For multilingual review, see AI translation quality assurance. If the observed error does not match the documented state, prepare a bug report.

Common questions#

Should error messages always explain the technical cause?#

Explain the cause when it is known and useful for recovery. Otherwise state what failed and what the user can do without guessing at an internal explanation.

Is apologizing necessary in every error message?#

Use the product's tone, but prioritize the problem and recovery action. Repeated apologies can add length without helping someone complete the task.

Can AI shorten translated errors automatically?#

It can propose alternatives, but verify meaning, terminology and interface fit with appropriate language review. A shorter sentence that removes the recovery instruction is a poor tradeoff.

Download the working files#

Download the copyable prompt and download the illustrative worksheet (CSV). Replace example data with your own verified inputs; the worksheet is a planning aid.

Browse the English AI workflow guides for related tasks.