Writing error messages users can act on
A good error message gives the user somewhere to go
I have a small rule for writing error messages: describe the next useful action before explaining the system’s feelings about what went wrong.
“Something went wrong” may be technically accurate, but it leaves the person holding the problem. They still have to guess whether to refresh, check a field, wait, contact support, or quietly give up.
Specificity beats drama For an education product, the difference can be very ordinary:
“Upload failed. Check that your file is under 25 MB and try again.”
That is more useful than “We couldn’t process your upload.” It names the likely constraint and gives the user a reasonable next step without pretending we know more than we do.
If the cause is genuinely unclear, the message can stay honest while still offering direction: “We couldn’t save your changes. Check your connection and try again. Your previous version is still saved.” The last sentence matters because it answers the panic hiding underneath the error: did I lose my work?
The copy should match the recovery I also try to make the button label carry its share of the meaning. “Try again” is fine when retrying is likely to work. “Review answers” is better when the user needs to fix something. “Contact support” should open a real path to support, not act as a polite synonym for “nothing else can be done.”
A useful review question is: if I saw only this message, would I know what action is available to me now?
Sometimes the answer is no because the product has not designed a recovery path yet. That is not a copy problem, although copy is often where the gap becomes visible.
The best error message is not the cleverest sentence in the interface. It is the smallest piece of language that returns a little control to the person using it.