User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

enter image description here

share|improve this question
10  
I 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. – DasBeasto Mar 9 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 Engelfrost Mar 11 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 Mar 17 at 2:05

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?

share|improve this answer
1  
To 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 D Mar 9 at 13:40
4  
you 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. – Yvonne Aburrow Mar 9 at 13:44
2  
Can 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. – hazzey Mar 9 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. – peterchen Mar 9 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. – TripeHound Mar 10 at 11:41

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                            |
+---------+---------------------------------+-------------------------------------------------------------+
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.