An error message is often the first part of a system a person sees when something goes wrong. It can leave them staring at an unfamiliar code, or help them decide what to do next.
The difference is not how friendly the wording sounds. It is whether the message gives enough information to move forward.
Name the problem
“Something went wrong” may be accurate, but it does not help someone tell a temporary outage from a missing permission or a mistake in their input. A useful message says what the system was trying to do and what prevented it.
That does not mean exposing internal details. A database stack trace is rarely useful to someone trying to save a document. The person needs a plain explanation; the person fixing the service needs a trace, request identifier, and enough context to find the failure. Those can be different messages for different audiences.
Give a next step
When there is something the person can do, say what it is. Check the file path. Sign in again. Retry after a short wait. If there is no useful action to take, be honest about that too.
I try to avoid advice that only sounds helpful. “Try again” is frustrating when repeating the action can create a duplicate or when the underlying problem will not change. The next step should fit the failure.
Errors are part of the interface
We often spend time polishing the path where everything works, then leave the failure path to whatever the framework prints by default. But failures are part of normal use. Networks drop, files move, and assumptions turn out to be wrong.
A clear error cannot prevent every problem. It can make the problem smaller: one thing to understand and one decision to make, instead of a mystery to investigate.