Describe the user’s problem
An internal error code may help a developer but rarely tells a customer what to do. Use plain language for the observable issue, such as an incomplete field or an unconfirmed request. Avoid blaming the user when the system is unavailable. Be careful not to claim that nothing happened if a timeout means the outcome is uncertain.
Place guidance where it is needed
Associate field errors with their inputs and provide a useful summary for longer forms. Announce important status changes to assistive technology without repeatedly interrupting ordinary typing. Keep visual contrast and use text or icons alongside colour. The message should remain visible long enough to be read and acted on.
Preserve work and offer recovery
Keep entered information where appropriate so a temporary failure does not require starting again. Explain whether to correct a field, retry later or contact support. Avoid encouraging repeated payment or order submissions when the first outcome is uncertain. Provide a reference or support route only when it is real and can help the receiving team investigate.
Test the wording with actual scenarios
Review validation errors, network failures, expired sessions and permission problems separately. Check that each message matches the real application state. Avoid returning sensitive implementation details, credentials or personal records in public errors. Use internal diagnostics for troubleshooting while keeping the customer-facing explanation concise and useful.
Your practical checklist
- Describe the observable problem accurately
- Associate messages with the relevant control
- Preserve work and provide safe recovery
- Review uncertain outcomes and sensitive details
Working through a similar question?
We’re happy to help you find a practical starting point.
Talk to AMGK