I'm testing a web app that has a cumbersome exception message for attempting to add non-eligible invoices to a payment system, see the image below. The developer sees no issue with this but its clearly awkward looking. Is there a good reference for current standards on how a message like this is designed? Common sense would suggest you create a generic message that doesn't include actual data tags to keep the message predictably sized.
-
10I don't have a reference/standards about how big messages should be but a good solution for this particular case is as after a set point, say three documents, don't list the names just say "23 invoices are not eligible for payment" with either an expandable list of names attached or highlighting the errors in the table below.– DasBeastoCommented Mar 9, 2016 at 13:11
-
I think this answer is very applicable to your problem (but perhaps not as much to the question) ux.stackexchange.com/a/405/40308– Josef EngelfrostCommented Mar 11, 2016 at 14:36
-
The developer sees no problem because this person is not looking at it through the eyes of the user. Perhaps you should get a second opinion? I guess the sensible answer is whether the length of the message stops being helpful for someone to deal with the exception.– Michael Lai ♦Commented Mar 17, 2016 at 2:05
3 Answers
tl;dr:
Some of the invoices are not eligible for payment. They were excluded from payment processing. [details]
Error messages should separate two things:
- Information for the end user (What they can do to "fix things")
- Diagnostics for support and for the developers
Of course the developer is happy because they see what they want. But it's not helpful for the user and likely to create support requests.
In very informal, statistically insignificant end user testing I found that for surprisingly many users, the difference between
Cannot open "doctorsoffice", the file is read only
and
Error: Cannot open "doctorsoffice", the file is read only (Code 5h)
is huge: including anything that looks "scary" or technical can trigger "error message blindness", i.e. the user, assuming the message isn't intended for them, fails to register the part that indicates what they could do themselves to solve the problem, and rather requests support (or simply gives up).
The second aspect where this message fails is telling the user what it means for them. I can't tell it from looking at your screenshot: is this a general information? Is this the result of my previous operation? Did it fail completely, or did the software process the other invoices?
-
1To get the message, I found ALL invoices for this customer in a simple search, selected them all and added them to the payment work flow (some had already been paid making them ineligible for payment). The ineligible invoices are all listed in the exception message (why?). The eligible invoices however are added to the work flow and a payment icon is assigned to each invoice in the table (sorry, not shown). The user knows which invoices were added so the message could be generic and reference that some invoices could not be added. That makes sense to me from the user perspective.– Mike DCommented Mar 9, 2016 at 13:40
-
4you might also like to point out to the developer that quite often there is a security issue with showing the system error. - e.g. if you show a stack-trace, you're revealing much more about the potential vulnerabilities of your system than you want hackers to see. Commented Mar 9, 2016 at 13:44
-
2Can you explain your example? You say that the results were "surprising" and then you ask the reader to "guess" which one has more responses. Without knowing which is error gives more of a certain response, I can make all sorts of wild guesses. Please make your example concrete.– hazzeyCommented Mar 9, 2016 at 19:41
-
1@hazzey: done :) -- To emphasize: what surprised me (and continues to do so) is that not only "typical" users are affected. Even developers, when confronted with a badly formatted error message from code outside their domain experience, repeatedly didn't make it to the second line of text where the cause was mentioned, simply solvable on their own. Commented Mar 9, 2016 at 22:40
-
1@MikeD On a lightly different tack: the operation you describe in your comment (select all, add to workflow) possibly shouldn't generate any errors/exceptions at all... if this is likely to be a useful shortcut for the user, the software should either not attempt to process ineligible invoices, or not mention the ineligible ones (the function becomes, explicitly or not, "Add eligible invoices..."). Exceptions should, IMHO, be more for when something that should be possible fails. Commented Mar 10, 2016 at 11:41
Error messages like theses are part of in app communication that include errors, warnings, information etc. the message above is too long, a better approach would be to have short title that says what went wrong and body content that explains the error in detail. Body content should be of 2 lines max and an option to expand. Also the lines are too long which is in violation of WCAG accessibility criterion 1.4.8 Means, people with vision disabilities and reading disabilities will find it hard to read texts that is longer than 80 characters (including space) in one line.
I think that you should separate your errors in two categories:
Application errors:
Here is when something is going wrong with the application, something like an error in the code, malfunction of it or something like that. In this case, there isn't much information relevant to the user, so error codes are a nice idea here.
With the error code, user can get some support from the application developers, and report it, so the user has something better than a simple non sense information (I mean something like a stack trace).
Is necessary to inform user that application failed, and encouraging user to contact support and report the issue. So user knows that there is nothing that he can do, and the developer could get some information from user:
The application had a problem and we cannot process your request right now, please report the problem, so we can assist you with this issue. Please report error code [00001] when reporting this.
Logic errors / User errors:
These errors occurs when the application is doing what is intended to do, but the error occurs, because of some other kind of error (User error, validation error, etc).
In that case, a good approach is informing the user that something wrong happened (in your case: Some of your invoices couldn't be processed). In that special case, is necessary to inform and give most information you can to the user, so he/she can fix the problem.
An example (based on @peterchen answer, he gives a very good answer about this case)
Some of the invoices are not eligible for payment. They were excluded from payment processing. Details
The details could be something like this:
+=========+=================================+=============================================================+
| Invoice | Problem | Possible solution |
+=========+=================================+=============================================================+
| 00001 | Date is outside permitted range | Review the dates of your invoice, so it matches this period |
+---------+---------------------------------+-------------------------------------------------------------+
| 00002 | Price includes decimals | Use only integers for your price |
+---------+---------------------------------+-------------------------------------------------------------+