Write error messages that help users recover

An error message should explain what happened and the next available action. It should not blame the user or claim data was saved when that is uncertain.

Set the editorial constraints

Give the writing teammate a clear audience, purpose and approved facts. Include a short voice sample when tone matters, and state what the draft must not promise. Save a draft file for review rather than treating a generated message as published copy. A final human edit should verify names, dates, claims and links against the source material.

Inputs for this workflow: Observed error conditions and actual recovery controls.

Work through the task

1. Map each condition to its real action.
2. Preserve any uncertainty about task acceptance or saving.

A brief you can adapt

Draft messages with a short title, plain explanation and action label. For a lost response, tell users to check task history before resubmitting.

The filenames above are examples. Replace them with your actual inputs and destination before submitting the task.

Review the deliverable

Walk through each error state and verify that the named action exists in the interface.

Where this approach can fail

Do not invent a retry, support contact or autosave guarantee that the product does not provide.

For the related desktop setup, see company playbook.