Friendly Error Messaging

Below is the error message shown after a session timeout for Bank of America Privacy Assist:

Image

This error attention caught my attention as it had an extra piece of information (somewhat?) unrelated to what I was doing at the time. Typically, the error message pattern is: (1) what went wrong? (2) why it happened, and (3) what should be the user next steps. What I notice above is an additional ingredient that can be called: “something for fun”. Now, the message above may be static, i.e. the user is always shown that piece of informational text warning about identity theft. But the treatment above does inspire the thought of having an extra part to error messages that is dynamic and gives something “random” and useful to the user.

For example, I’m thinking as a pattern for a fatal error page, have something like:
1. Something went wrong
2. Here is the fun fact of the day

 

Fidelity Lost All of My Money

Fidelity account view (post login) during a site maintenance:

Image

Portfolio Total for the account is listed as $0.00

Image

Initially, this scared the daylights out of me – did I really make such poor investment decisions that lead to losing my entire portfolio?!?

Nope – just a false alarm. Better design would be to write “Not available” similar to the first page.

Great Read on Error Handling

As mentioned before, I’m very passionate about user experiences pertaining to error cases. How the error is handled, what is shared with the user and what is left out, how much technical jargon is used in the content, the length of the content, the graphics of the page (or part of the page) of the error message, and the list goes on. 

I found a great site (from an unlikely source!) that captures error messaging best practices

Image

Error Messages

Because of my current job, I’ve had to work a lot with how best to handle errors. For some errors, the root cause can be attributed to the user i.e. (1) the user needs to provide a specific (and correctly formatted) piece of data for the flow to proceed or (2) the user did something “wrong” (I use the word in quotes because the customer is always right, and we need to be careful when labeling their actions as wrong). For other errors, the root cause can be attributed to the software itself i.e. something went terribly wrong in the code and the user cannot proceed in the typical manner the user is used to (aka fatal errors).

My philosophy on errors:

Give the user three important pieces of information (if you can):
1. What happened? Explain, as concisely as possible, what went wrong.
2. Why it happened? Explain, (again) as concisely as possible, the root cause of the problem – in language the user understands (don’t tell the user that there was a Null Pointer Exception!!).
3. What next? This is the most important step. Explain to the user what they need to do in order to resolve the issue.

For fun, here is an example of a fatal error (from Facebook):