Can errors be too simplified/generic (even for non-technical users)?

Question

I was using a very popular application today and something about its behavior baffled me.

A core feature wasn't working and there was a very short error message that simply expressed the fact that this core feature wasn't working - absolutely no more information on the interface. The problem is that, after googling, I found out that nobody among its users seems certain about what the message means, but essentially the cause could be any of the following:

• The user provided invalid parameters.
• The server could not be contacted.
• The server's algorithm found no matches to the query sent by the feature.

Normally, I can understand the reasoning behind simplifying error messages, especially in applications that target non-technical users: the average user doesn't usually care about why the application doesn't work, the average user is not qualified to fix the problem, the average user may not be willing to send an error report, etc.

But here we have at least three vastly different scenarios and even the average, non-technical user could respond very differently to each one. The user could easily know if they should try other parameters, if they should check the connectivity with the service or if they should simply wait and check back later. And yet, any information that would allow this distinction is absent from the completely generic and simplified error message.

Until now, I thought error messages should be simplified but only as long as they still communicate whether the problem is something the user can do something about. Am I correct about this subject (and is the described app badly designed when it comes to its error messages), or am I wrong about it (and the app is, in fact, correctly following established UX conventions on the matter)?

Answer 1

Yes.

MSDN says:

A well-written error message provides the following information to the user:
What happened and why?
What is the end result for the user?
What can the user do to prevent it from happening again?

That article also says that the length of the text doesn't matter. Personally I disagree - don't make me think. Users should be made aware of what has gone wrong, why, the result and preventative measures, but try to keep that text as short as possible so the user can close it quickly.

As a developer, I like JavaScript's errors, such as:

Uncaught ReferenceError: method() is not a function

That comes with a line number. It's useful to me because it tells me what happened, where (and therefore where I should go to fix it), and roughly what I should do.

As a user, one of the best error messages I've seen is this:

The network connection was lost. Please try again later.

It's short, easy to understand by non-techies, it gives a good description and it tells me what to do so I don't have to think.

As the MSDN article also says, don't use generic messages to cover lots of errors unless you don't know what the cause was. Be specific.

So yes, error messages can be too generic, but there is a balance to be struck. Too technical and users will just get annoyed and close the window, not enough detail and they don't know what to do.

Answer 2

Yes, error messages can be too simplified and they can be too complex. It all depends on who the end user is. Messages generated for an engineer might be much more detailed than ones generated for an average user.

Ideally an application will prevent invalid choices from being made but there are always things that go wrong that need to be reported.

Any reported error message should:

• Be informative.
• Be easily understood.
• Help the user recover from the error.

I always make an extra effort to review messages my software generates and have empathy for the person on the other end of the screen.

Answer 3

Users must have a good conceptual model for the system, to understand any message. As Donald Norman says at his excellent book The Design of Everyday Things:

"Without a good model we operate rote, blindly... we can't fully appreciate why, what effects to expect, or what to do if things go wrong"

The user's conceptual model for the system does not have to be as detailed and accurate as the conceptual model of technical people, but it has to be useful enough to enable the user to perform some simple actions when thinks go wrong.

We can build a useful conceptual model for the system through a good user interface, contextual help, training etc. Alternatively we can exploit existing knowledge of the average user.

The messages should be written at the level of user's conceptual model.