Unexpected Errors: Were They Ever Expected, Anyway?!

I'm sure you've seen error messages that say something like "Unexpected error occurred. Contact your system administrator." Fairly useless error messages I would say, actually, and an approach I do not promote in my team.

When, for example, is an error message ever expected? And how do you contact your system administrator (even if you know who or what that is)?

Figure 1: Why Not Just Ask Alice?

I was reminded of all this as I read the section about "Make sure your error messages cover unexpected problems" in the UX Matters article "Avoid Being Embarrassed by Your Error Messages". However, in the enterprise applicastion space, additional requirements should be met for these "unexpected errors":

Firstly, a unique message identifier (or number) should be attached to the message itself. This can be disclosed progressively, coming after the message or made visible by way of a 'More Details' option on the message dialog for example. These identifiers can serve different purposes: They can allow the user to search on the number and find a solution is the most common one.

However, in many enterprise scenarios this option is usually of little use to the end user. Instead, help desk or support analysts can use the number to search for, and record, solutions in knowledge bases. Being the same identifier across translated releases, as well as the English release, means that the analyst does not need to translate the message into English to find a solution too. The analyst looks up the identifier.

Secondly, end users should never be told to contact their system administrator (figure 1) or to try and recreate the error or type out what they were doing (even if they could). The message handling framework should do all that automatically for the user. Oracle Apps refer to this process as incident creation (or alerting) and diagnostic logging.

When serious messages are shown to the user an incident is automatically raised and diagnostic logs (usually) created too, alerting the help desk to the issue and collecting all the necessary background details for the help desk analyst. In these cases, a straightforward message text tells the user that their problem has been recorded for them.The technical details are not disclosed to the end user, but instead, the help desk can use the incident and diagnostic tools to deal with the cause of the problem (figure 2). End users should not be dealing with complicated tech stack details. They can't do anything with them to fix the problem.

Figure 2: Possible Error Dialog for Non-user Actionable Message

All too often discussions and guidance about error messages are disconnected from the Support framework provided in the enterprise space and the reality of applications security and roles. A posited solution based on something like "Unexpected error. We didn't think you'd ever see this message, but you have. Please contact us and give us this error code: [Error Code]" doesn't really move the user experience argument very far in the right direction of recording why an user-unrecoverable error happened automatically and doing as much work for the user as possible.

Remember that "unexpected" error messages the beginning of a customer engagement process with the help desk and possibly support analysts, so make it as easy as possible.