Understanding Defaults and Notifications (or, why I hate my dishwasher) – Part 2

This is part two of a two part series. In part one we went over the guidelines around using defaults and talked about some pitfalls to avoid. You can go back and read it at Understanding Defaults and Notifications (or, why I hate my dishwasher).

So, last time we finished talking about my dishwasher’s use of defaults. Just to recap, the designers of my new dishwasher decided to put in a default setting so that the machine would automatically buzz loudly five times after the dishwashing was complete and then continue to buzz periodically for the next hour. We talked about the use of this default and some guidelines for creating good defaults.

Now let’s consider that this default setting was a default notification setting. Notifications, like defaults, also have a couple of guiding principles around their use. In fact there are really only about three questions you can ask yourself to try to avoid making a bad one.

Is this Really Important Enough to Notify the User?

Before you go any further, ask yourself this one question. Maybe ask yourself this a few times because it’s really very important. Users are constantly bombarded by notifications that interrupt them from their tasks. Unless what you’re trying to tell the user is that this is something they truly care about, maybe it’s better that you don’t tell them. If users are notified too often about unimportant things then they might decide to abandon the device or service.

So, in the case of my dishwasher, was the fact that the dishes were clean that vital to users? I’d hazard a guess at no, but for the sake of argument, let’s say that the designers talked to their users and found that most of them needed to be informed when their dishes were complete. You’d then move onto the next question.

Are you Using a Proper Delivery Method?

After you have determined that the message is important enough to alert the user, you need to consider what delivery method you are going to use. You need to decide if a sound alert, a visual alert, a tactile alert, or a combination of these is best suited to the context where the user will be receiving your alert.

For example, a sound alert for a text message in the middle of an office meeting would be too disruptive. Any benefit to the user would be outweighed by social embarrassment. A sound alert for a text message while at a loud concert would also not be suitable, but for very different reasons.

In addition to deciding on the overall method, you also have to decide on the qualities that this alert will have. If it is sound feedback will it be a gently playing tune or an abrupt siren? If it is visual feedback will it be coloured red or green? And if it is haptic feedback, how strong will the vibration be?

Each of these elements also greatly affects your users’ reactions to the alert. Imagine if a fire alarm sounded like an email notification or vice versa?

So, was my dishwasher using the proper delivery method? While I was willing to give the designers the benefit of the doubt for the first question, I think this second question is a clear ‘no’.

Choosing a loud buzzing noise to alert people is not keeping in mind the context in which dishwashers are often used. A lot of places around the world use time of day electricity metering. With these systems, electricity cost varies depending on the hour, and it is often the cheapest at night. This causes a lot of users to run their dishwashers at night when the rates drop. In this case, the use of a load buzzing notification would lead to many users being rudely awakened when their dishwashers finished.

So, it is clear that “loud” is not a good quality to have in this alert, but I’d suggest changing the delivery method entirely. Knowing that your dishes are clean is not knowledge that needs immediate action (in fact, you often even want to wait a bit for them to cool down). A sound alert is an intrusive call to action; it will get your attention immediately, and disrupt what you were doing. In this case, a visual alert might be better suited for the task. If a light on the dishwasher were to simply light up when it was done, then the users wouldn’t have to be disrupted from their tasks and could instead notice that the dishwasher was done in their own time.

So assuming that my dishwasher designers has decided to use a more appropriate delivery method, you’d then move on to the final question.

Are you Giving Enough Information?

In the dishwasher example, things are pretty simple; all you have to communicate is one piece of information: that the dishes are done.

As the information gets more complex, the question of whether you’re giving the user enough information becomes more challenging.

The biggest offender of this seems to be error messages. When something goes wrong, you not only have to tell the user what happened, but also how to fix it. As you might imagine from the use of italics, the second part is often left out. As much as we try to prevent errors, they happen. We need to accept that and make sure that when our systems fail, they fail gracefully. Keeping users informed and giving them enough information to help resolve or prevent this problem from occurring again is important in preventing user frustration.

It is also important to be very precise when giving users directions and to make sure that you use their language. It would be better to write “Sorry, but the computer does not seem to be properly connected to the TV. Please check the cables and make sure they are secured snuggly.” Rather than, “Error 14839”. It’s not a good idea to expose the inner workings of your system to the user.

Displaying complex codes and terminology does not make users feel like your system is more impressive; rather, it’s more intimidating and frustrating. If you really can’t write out a sensible message to the user because you don’t know what went wrong, sometimes it’s just better to write “Sorry, something went wrong”.

If you stick to following these three principles then you’ll be able to catch bad notifications before they become a problem for your users (and you!).