Error fatigue and desensitization

DJ Larkin
DJ Larkin
Sep 4, 2018 · 6 min read

By DJ Larkin

Originally published November 5, 2012 2:42 pm


Have you ever had a problem in your software that’s been around for so long that you don’t seem to notice it anymore? Be it a log message, glitch in the UI, or workflow annoyance, you can become desensitized to these problems. This is one of the reasons why I love new hires. You can count on a new hire to point out the errors you no longer notice, since you’ve seen them so often.

So, how do you prevent this desensitization from happening? Depending on how your application is built, you’ll have various types of warning and error messages that can appear to the user. For the purpose of this post, I’ll use the generic term user to refer to QA, clients, support, developers, or anyone else who’s using the application in some capacity. Some messages are popups, inline messages, icons, highlights, outlines, colors, email messages, logged events, messages stored in the database, etc. Regardless of how you notify or warn the user, it should be clear as to what’s happening and what to do about it. Most developers have a good handle on some of these areas, but can very easily neglect others. There are a lot of guidelines on writing clear messages scattered around the web. I’m not going to delve in to this too deeply, but rather focus on using them properly.

Application Warnings and Errors

Microsoft’s User Experience Interaction Guidelines state:

Effective error messages inform users that a problem occurred, explain why it happened, and provide a solution so users can fix the problem. Users should either perform an action or change their behavior as the result of an error message.

An effective error message is a fantastic tool.

Aiming for an error free application is a noble, but unrealistic goal. However, it’s good to take some things away from this mindset:

  • There should be no warning or error messages in the standard/typical workflow of your application.
  • Only display an error when there’s an actual error.
  • Don’t display the same error too many times.
  • If it’s a message that’s aimed at a non technical user, try not to get too technical in the message.
  • Let the user know that they cannot continue working without restarting/reloading the app, if that’s the case. Don’t let them continue if doing so will cause problems.
  • If you can handle it gracefully, and without interrupting the workflow, then it should go in the logs instead (see below).

Users that see lots of warnings and errors pop up in front of them become trained to click them away without paying attention to the content. In the cases of some applications, this means they can continue working without any noticeable problem and become trained to ignore these messages. If only one in twenty, fifty or a hundred of these messages is meaningful, chances are high that it will never be seen by the people that need to see it. Excessive use of these messages can interrupt the user experience, create unnecessary support calls, bug reports, and headaches for a developer.

User Interface Warnings and Errors

This may seem to be a similar topic to the one above, but there are subtle differences between application and UI errors. For this purpose, I’ll consider a UI error to be a failure of the interface itself, rather than a message displayed in the interface.

The UI should be used to inform the user of what’s happening and what they need to know. Informing, without overwhelming or annoying the user, is the highest priority when developing this area of an application. Some examples on how to accomplish this are as follows:

  • Show some indication that the page is processing information.
  • It’s hard to know if something’s wrong when you click a button and then nothing happens.
  • A UI that is processing information is not the same as a UI that is slow or unresponsive, but your users don’t know that. Give them information when this is happening, so that they can tell the difference between intentional and unintentional wait times.
  • If there’s a long processing or load time, show some indication that there’s work being done. Progress bars and messaging are helpful.
  • Users can be frustrated by long load times, but over time will become accustomed to them. Don’t allow them to get used to this, especially if you want them reporting slowdowns where there shouldn’t be any.
  • Don’t tell a user they shouldn’t do something, simply prevent them from doing it.
  • A good example of this is a form submission button that asks you not to click it multiple times, but to simply wait for things to process. Prevent the user from doing this, by disabling the button after it’s clicked, and you’ve saved an explanation.
  • Avoid the “I clicked on it and nothing happened” syndrome. It’s frustrating for the user, support, and developer to try to track down these problems, because they’re so vague.
  • Be meaningful in your messaging.
  • An icon may be used to convey information, but use legends, tooltips and labels to provide additional information. Not everyone will understand what a particular icon means in places where the information isn’t visually discernible.
  • Highlighting something with a color may seem meaningful, but it can be frustrating if there’s no other indication of what this means.

You need to be clear to the user what is expected and unexpected behavior. You don’t want a user to ignore a warning light, so make sure they understand what it means. The user interface is going to be the most support and client-focused area of the app. Therefore, you’ll need to be much less technical, and much more forgiving here.

Logs

While the UI is the least technical aspect, your logs should be the most technical. They should contain lots of information, but still be readable to the people who will need to go through them. First and foremost, you should be creating logs of some kind. There are few tools better than logs for tracking down bugs in every iteration of a product, from development to production. Here are some ways to improve logging:

  • This is the front line, the first place you’ll start to desensitize yourself to seeing errors.
  • You should be able to look at a set of logs, and know that every message is meaningful, and relevant to it’s severity.
  • Every error in your logs should be an actual error.
  • If you’re logging something as an error that you never plan to fix, it’s not an error. It needs to be logged as something else: a warning, information message, or something else.
  • Logs are usually simple text. If you’re concerned about them taking up too much space, use a compression method. Text files tend to shrink down significantly when compressed.
  • Logs should be technical, but human readable. You want errors to be clear and understandable, not cryptic codes.
  • Use proper grammar, spelling and full sentences in your logs, this makes searching for a specific error much simpler.
  • Batching errors and logging them once can keep your logs simple and clean. Repeating a single message hundreds of times only causes the user to skip through the logs, with the potential for missing something.
  • Sometimes, a message isn’t an error until it happens too often. Use thresholds in your logging, and capture this. For example, if something happens once, use an information. Five times is a warning. Fifty is an error.

While this is important to a developer, it becomes significantly more important as you pass the product down the chain. Here at work, QA should be able to file a bug for every error they see. If they have to make judgement calls as to which error messages they see are actual errors, they are being trained to ignore errors. Once it gets past QA in this state, the support team is expected to do their due diligence and find the representative stack traces and error messages in the log for problems reported by clients. However, it can be very difficult to spot a real error in a sea of false error messages. It becomes difficult and frustrating to find problems this way, and people will adopt this as the status quo. Don’t allow that to happen.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade