Error messages are not good per se, after all, they tell you something has gone wrong. It is a double annoyance for the user if they do not understand why the error has occurred and what they can do now. Reactions are different: one person curses loudly about the software, the other would like to throw their mobile phone out of the window and the third will perhaps never open the app again. But even though error messages have such high frustration potential, they are often neglected in the creation of a UX.
What is the Reason?
Sometimes a UX creator does not really know which errors can occur. They assume that the developer is more familiar with it and leaves this topic to them. The result looks like this:
The users are informed in English about a problem of which they neither knows why it occurs, nor what they can do about it. Instead, they are informed of the backend name and the number of the error.
Or the UX creator deals with the definition of all errors, but he is not responsible for writing the UI text. The copywriter, however, does not know the various errors. Possible result:
All error messages get the same, not very meaningful, sentence. But at least we tell the user that we are sorry.
How can we do it Better?
First, we should consider every error case individually and give the user a specific error message. Only in this way can we really tell the user what went wrong. So, like this?
The user learns what happened and is happy? Not quite. It remains unclear what they can do. Perhaps we should therefore supplement that.
It would be interesting to know how many users read this error message and then actually know which of the three buttons they should choose.
Obviously, it does not just matter what we tell the user, but also how. But let’s take note. Effective error messages show the following information:
- What went wrong and, if possible, why did it go wrong?
- What can the user do to solve the problem?
On the way to the Perfect Error Message
As the example above shows, error messages should be kept brief and clear. The user is already annoyed that something has gone wrong, now they do not want to read a novel about it. The goal is thus: as short as possible, but as detailed as necessary, so that the user gets all necessary information.
As for all UI text, it is also valid for error messages that we should speak the user’s language. And this is not just the language of the country, but also doing without specialist jargon, which is unknown to the user.
We usually know what language our users are speaking. So an error message language class is unnecessary.
In addition, it cannot hurt to be a little friendly and polite. And in all circumstances, we should avoid blaming the user. Sounds logical, but still, it happens again and again.
For example, Word complains to me that my document contains too many spelling and grammar errors just because it cannot deal with the many technical terms.
A failure report could even be the occasion for a small joke to keep the user’s mood up. Of course, you have to make sure that the tone matches the product and the target group. But if that is given, why not even try this:
Or even this, with a nice graphic:
Thus, well-considered error messages can even end up benefiting the brand identity of the product. And let the user continue with a smile rather than a curse. Reason enough that we UX creators should accept the issue and not only want to think about error messages, but also to formulate them.