Bad error messages waste time because they hide the thing you actually need to know.
Something went wrong is not useful. Neither is a stack trace dumped on top of a user who cannot act on it. A good error message does three things. It says what happened. It says what to do next. And if the system needs something from the user, it says that plainly.
That sounds simple, but a lot of software gets this wrong. Teams often write errors for themselves, not for the person reading them. So the message is technically true, but practically useless. It might be fine in logs. It is not fine on a screen.
Say what happened
The first job of an error message is to describe the failure in plain language.
If a form field is invalid, say which field is wrong and why. If a payment failed, say whether it was declined, timed out, or could not be processed. If a request did not reach the server, say that instead of pretending the app knows more than it does.
I think this is where a lot of systems get lazy. They use generic wording because it is easier to write once and reuse everywhere. That is convenient for the code, but it pushes work onto the user. The user then has to guess whether the problem is their input, the network, the backend, or something else entirely.
Say what to do next
The next job is to give the next step when there is one.
Sometimes that step is obvious. Try again. Check the value. Sign in again. Wait a minute and retry. Refresh the page. Contact support. Those are all better than nothing when they are accurate.
The important bit is that the message should not just describe the failure and stop there. If there is a recovery path, say it. If there is not, say that too. A clean We could not save this right now is better than a fake promise that the user can fix something they do not control.
Say what the system needs
Good errors also tell the user what input or condition is missing.
That might be a required field, a file that is too large, a session that expired, or a permission that was not granted. The message should make the requirement visible instead of burying it in policy language.
This matters because a lot of error handling is really contract handling. The system needed a date in a certain format, or an authenticated session, or a valid identifier, or a supported file type. If you do not say that clearly, the user gets stuck repeating trial and error.
Keep it honest
One rule I like is that an error message should never pretend to know more than it does.
If the system timed out, say it timed out. If a remote service failed, say that the request could not be completed right now. If you do not know whether data was saved, do not imply success. That kind of honesty matters because it changes how people recover from the failure.
It is better to be specific and slightly boring than confident and wrong.
Good errors reduce support
This is the part that gets ignored when teams treat error text as decoration.
Better errors mean fewer support tickets, fewer repeated questions, less time spent digging through logs, and fewer people staring at a screen trying to decode the same failure. They also make the software feel more finished. Not because the app never fails, but because it fails in a way that makes sense.
That is usually the standard I care about. Not polished wording. Not clever wording. Just errors that help the next person move forward instead of making them guess.
