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)?