An error message is part of the workflow, not a decorative notice added after the application is built. It should explain what happened at a useful level, what the person can do next and whether their work has been saved. For a business system, the most costly confusion is often uncertainty: staff cannot tell whether to retry, wait or recreate the task somewhere else.
Match the message to the actual outcome
Imagine a Wagga Wagga supplier submitting a customer order. A missing delivery address needs a different response from an unavailable accounting service. The first can be corrected immediately; the second may need a retry or an internal follow-up. Avoid one generic message for every failure. If the order was saved but the accounting update is pending, say so and provide the order reference. Telling staff the entire action failed may encourage them to create a second order, adding another problem to the original interruption.
Preserve useful work
Keep entered information available when validation fails, and identify the fields that need attention. If a sign-in session expires during a long form, plan a safe route through reauthentication without unnecessarily discarding the draft. Decide which information may be retained and where; sensitive material may need different treatment from an ordinary product enquiry. A clear save state helps users understand the boundary. Use labels such as draft saved or changes not yet saved only when the application can support that statement with the actual storage outcome.
Handle technical failures deliberately
MDN notes that a Fetch API request does not automatically reject merely because the server returns an HTTP error such as 404. The application must inspect the response and interpret the result. That technical detail has a visible consequence: a completed network request is not necessarily a completed business action. Ask the developer to demonstrate validation errors, server errors and interrupted connections separately. Customer-facing messages should remain understandable, while a reference code can help support find the technical details without exposing them in the interface.
Write the recovery message before testing
For each important action, draft the failure message alongside the success message. This reveals unanswered questions about whether the action is safe to repeat. Rehearse a failed save with real staff and check:
- The user can tell what was saved and what remains unfinished.
- Correctable fields are identified without erasing unrelated answers.
- Retrying cannot blindly duplicate an important business action.
- Support receives a useful reference and the user knows when to contact them.