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.
Error messages should separate two things:
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
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?
I think that you should separate your errors in two categories:
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:
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)
The details could be something like this: