o.rydberg

Passion for software development



How to Avoid Error Messages

2016-11-12

What is the absolute best error message? Well, I think that the best error message is no error message at all. The second best error message is to have a very small error message, but then the user needs to get the information about the current state of the application in some other way.

Fixing the problem

What am I talking about? Avoid having error messages that sounds really strange? Maybe it dose, but if we could fix the problem for the user instead of giving the user an error message, then no error message is needed. Some classic examples of this is when you enter a phone number like 08-11 22 55 in some application or at some webpage and hit the submit button. Then you get an error message saying that "-" is not an allowed character in a phone number, so you remover that character and hit the submit button again. Now you get a new error message saying that space is not allowed in the phone number and then you hit the submit button again. Finely it accepted your phone number. So I don't think that you where a very happy user after this experiences. But all of this could have been avoided if the application or webpage would just have taken the extra effort to clean these characters out of the phone number field. This would have been one way of avoiding to have an error message.

One other example of where we can try to avoid giving an error message to the user is if it's not possible to connect to your server right now. It's easy to just open a big error message in the screen for the user directly. But I think that it's better, to do at least one retry before giving the user an error message. By doing the retry, we might have avoided giving the user an error message. Retries are even more important when the user is using a mobile device, sins they might be in a temporary radio shadow.

If it's some information that the user wants to send to the server when the user is in the radio shadow, you could also store the information locally until the device gets a connection again and send it then instead, to avoid showing a error message.

Why is it good to avoid error messages?

If you have been able to create a very simple and smooth flow through your application, that work would be a bit of a waist if the user would be interrupt with an error message for instance. So, one thing that slows us humans down is interruptions and then we have to start all over in our thought process. If we are in a very good flow when we are working, then our high speed will go down to zero directly if we get interrupted by something (error message for instance). So avoiding error message can increase the productivity significantly. The longer and more complicated an interruption is for a user the longer time it takes to get back in the flow again.

Cognitive load refers to how much "brainpower" is required of a person to do something. The more contextual details of a task that a person has to keep in the working memory and high level of focus is needed the higher the cognitive load is needed for the task.

One error message example is if you add a choice to the error message the user need to decide what to chose and that increases the cognitive load and increase the time before the user can back into flow of the application again.

Minimizing the error message

So, if you could not fix the problem automatically in any way, you need to give the user some kind of message about the problem. We should try to minimize that message as much as possible. What? Should we not give the user as much information as possible? Yes, you are correct the user needs as much information as possible, but they should already have as much information as possible before the error message is displayed to them, so the actual error message should only have to be some kind of guide on how to solve the problem that occurred.

As we discussed earlier in this article, if the user needs to decide something in a error message the cognitive load goes up and the flow speed goes down. So the next level of design rule after avoiding having error messages is to have error messages where the user don't have to decide anything. Having the error message in the center of the screen on top of the application and making the user have to click on the OK button will increase the interruption and flow speed for the user. So, putting a error message in the corner of the screen or even better in context of problem would not interrupt the user as much.

One other rule with error messages is not to wait with giving them to the user. The reason for this is that the user might have moved to a different type of context in the application when you give the user the error message. By then the user might have forgot the context that your error message is about and again the cognitive load will go up and the flow speed will go down. So tell the user as soon as possible about the problem to minimize the interruption and the speed for the user. Doing this will also minimize the amount of information that you have to give the user, so that he or she would understand what the problem is about.

I have now bee telling you about not creating error messages that doesn't interrupt the user, but if it is something that the user really needs to fix before continuing with the work flow, the user needs to easily see the error message. You can do this for instance with colors, so you can use a color that has a big contrast compared to the rest of your application.

In this article, I will not tell you how to create a traditional error message like a big window on top of everything where the user has to select one of 3 buttons to be able to continue to use the application. I'm not telling you this, since this is exactly what I want you to avoid to do. Instead try to avoid error messages and if not possible create small guides for the user, where you don't put the blame on the user. Instead help the user to correct the problem and move on in the work flow. This will give you happy users!

Interesting Links: