UX nerd

Around a month ago, I got to do my first solo project. With great power comes great responsibility and, luckily, the ability to choose the subject that better suits my interests :) And this is how I embarked on the redesign of browser error messages.

Browsers are old. It’s weird. I would have thought that major industry players would have figured out this kind of core issues by now. Error messages are not about new or experimental interactions, their design is probably as linked to basic UX design principles as can be. That’s why I was startled when I started to get the answers to my questionnaire… users mistaking DNS errors with HTTP 403 response codes and attributing SSL certificate warnings to malware. There’s a lot of educated talk on the web about how bad some error messages are, these however are savvy users’ rants and none of them come close to describing how the average users misses on their web experience, one of my participants even describing the experience as “distressing” :S

Anyway, after a week of questionnaires, qualitative analyses, guideline drafting and prototyping, I came to understand why error message design is not a popular discipline and some other interesting conclusions.

I’m posting the guidelines I came up with here, and if you feel like reading the whole analysis and taking a look at my redesign, you can download it from here.

These are my guidelines for error message design, illustrated with some examples taken from the browsers I studied (IE, Firefox, Opera and Chrome):

1. Explicitness: messages should make clear that something has happened. Either there was an error or the system is trying to warn the user because it encountered a potential threat. This error message (in the form of a Live Search result page with no results) appears in IE when the address includes a character that is not allowed as part of a URL. It fails to be explicit. The users I interviewed thought that they got this page because the browser had misinterpreted their intentions: they wanted to go to a website but the browser “thought” they were trying to look for something using the search functionality embedded in the address bar.

2. Human readability: error messages targeted to people should be readable by people. They should use human language and avoid obscure codes. This Opera error message is an example of what shouldn’t be happening: the term “illegal URL” accompanied by the ASCII code of the disallowed character carries no meaning in human colloquial speech.
3. Neutral tone and politeness: error messages should carry a neutral tone and be polite, avoiding placing the blame on the user. In this Firefox message, where it reads “did you make a mistake [...]?” could be, according to this guideline, rephrased as “are you sure this is [...]?”.

4. Precision: error messages should tell the user exactly what happened or allow them to diagnose what the problem is. As different users have different levels of expertise and facing the risk of being overly verbose, this is arguably one of the trickiest principles to master. This Chrome error fails to achieve this (even in the case when the user has typed the URL in the address bar, it mentions a broken link) while the Firefox error above was found to be too verbose for the users to read.
5. Inclusion of advice: errors should include advice for the user on what to do next, how to tackle or solve the problem. Error messages are part of a dialog that is taking place between the user and the system as a strategy leading to solving a problem that has arisen. In such a context, the responsibility of an error message designer does not end once the message is displayed. Suggesting and anticipating user response is part of error message design. When designing an error message, it is important to keep in mind that how much the user will trust an error message and will engage in performing a suggested action (presumably enhancing his/her experience) depends on the accuracy and simplicity of the advice. This Opera error prompts the user to check his/her Internet connection and this is what the users I interviewed said they would do if they got this error: “check the cables, check the router, look at the Wi-Fi icon”.  Checking if the user has an active Internet connection can be done automatically by the browser when this kind of error is triggered saving a lot of useless work and frustration on the part of the user. This guideline is probably the single most important piece of advice in the quest to create intelligent messages that can effectively dialog with users and to end the current paradigm that makes users see error messages as a dead end.
6. Focus on the user: error messages are, from the point of view of the user to whom they are targeted, a response of the system to an action performed by the user. As such, to understand from his/her point of view what caused this error and how to avoid it in the future, the user is interested in seeing a message as a response to his/her action and not an obscure technical complication that arose from the action. From the point of view of the user, the error from which Opera shows this message may either be the result of the user clicking on a broken link or the user misspelling a URL the fact that the address could not be resolved because it contained disallowed characters (although it is valuable information for the user and can help troubleshoot the problem) is not a straightforward response for his/her action.
7. Conciseness: error messages should be short and to the point. They are an interruption to the optimal process in accomplishing the user’s action and they should consume the less possible time. Lack of conciseness or overly complicated messages, can result in the user disregarding the message and abandoning their goal. In the case of this Firefox error message, for example, even if the first suggestion pointed to the right course of action, users failed to read the message at all, misidentifying the cause of the problem: they said that if they got this message they would check their Internet connection.

8. Context: error messages, when possible, should be context relevant. If the same technical complication occurred in two different scenarios (in this case, for example, when clicking on a link or typing a URL which can be discriminated by the browser), context can be the answer to providing sensible error messages. In the case of error message above, asking the user if he/she made a mistake when typing the URL is irrelevant if the user just clicked on a link, as well as in the case of this Chrome message stating that the link is broken is inaccurate if the user typed the URL.
9. Appropriateness and potentiality: error messages, and especially warnings, should convey the right degree of alarm. It should be apparent for the user that the danger involved in accepting a certificate that is valid when the date settings in his/her computer are incorrect does not offer the same security risks as accepting a certificate whose serial number was issued for a different website. All of the SLL certificate warnings of the browsers I studied (IE, Opera, Chrome and Firefox) failed to do this. This can be frustrating for the user that misses on his/her experience, or worse it can result in the user disregarding the importance of more serious warnings.
10. Clarity of origin: error messages should make clear that they are a normal part of the interaction with a system and they are not inherently something bad. As well as the user is not to blame for an error, error messages should also be designed in a way that avoids the system as being perceived as defective on the part of the user when this is not necessarily the case. For example, when users were presented this message, although it represents the intended response for the user action, users considered the system to have malfunctioned and mistaken their intentions.