Make error messages explain the next useful action

An unexplained failure can turn a small interruption into a support request or a duplicate business action. The message is part of the recovery process, not decoration after an exception. Product owners should review errors against a simple question: can the intended user take the next useful step without guessing what the system already did?

Name the failure at the right level

Separate a value the user can correct from a permission restriction or a temporary service problem. Replace a generic failure label with the affected task and the available next action. Avoid blaming the user when the system cannot establish the cause. Do not display internal stack traces as business guidance.

WAI recommends checking input on the server as well as in the browser.[1] Plan for server rejection even when the page initially accepts a value. The resulting message should explain the business rule rather than expose an implementation code that only a developer understands.

State what happened to the work

Specify whether edits remain on screen, a draft exists, or the final outcome is unknown. If a connection disappears after submission, a retry may be inappropriate until the application checks the existing request. Recommend a status lookup or another recovery route that matches actual backend behavior.

When a dynamic error qualifies as a status message, WAI describes making it available to assistive technology without moving focus.[3] Coordinate visible text with that announcement. A screen reader user should receive enough context to identify the affected operation, not only hear an isolated error number.

Hypothetical example: an expense attachment

A hypothetical employee submits an expense with a receipt file. The file service rejects the attachment because its type is unsupported, while the expense remains a draft. The message says which file failed, lists accepted types, and offers replacement without deleting the entered amount.

A different interruption occurs after the employee sends the expense for approval. The application cannot confirm the result. Instead of instructing an immediate resubmission, it offers a check of the expense status. The two failures require different wording because the available evidence and safe next actions differ.

Review the complete recovery route

Ask support staff which information helps them resolve an unresolved case. A safe reference code can connect the user report to internal diagnostics without exposing technical details. Pair that code with plain guidance and a reachable support route. Do not make the code the entire message.

Specific messages require maintenance when rules or services change. Keep the text close to the responsible product behavior and review translations together. Clear wording cannot repair a missing recovery mechanism.

• Identify the affected operation in ordinary business language.
• Explain whether input or a saved draft remains available.
• Offer only actions the application can actually support.
• Separate a confirmed rejection from an unknown submission outcome.
• Test the recovery route with keyboard and assistive technology users.