Rules for writing error messages. Why are error messages usually written incorrectly, and how can this be corrected? Error messages about incorrect data entry

Briefly: Conventional wisdom says that good bug reports should be polite, accurate, and constructive. With the advent of the Web, several more requirements have been added to these requirements: make the error message clearly visible; in case of an error, the user does not have to spend a lot of time correcting it; Train users as you go.

The rules for creating effective error messages have remained the same for 20 years. Good message the error message should be:

Obviously indicate that something is wrong. The worst error message is one that was not created. If users make a mistake and don't get any response from the system, that's the worst thing for them. For example, an application working with by email has several situations where an indication of the error that occurred would be clearly useful. Let's say you sent postal message, which was safely swallowed by the system, but never reached the recipient. Another example? You say in the letter that you are attaching a file to it, but you simply forgot to do so. This is where this stupid MS Office paperclip would find a job: " It looks like you wanted to attach a file to your message, but didn't. Want to do this?"
To be written in human language rather than using mysterious codes and abbreviations like " a type 2 error occurred".
Be polite and do not blame users for being so stupid or for doing something wrong, such as in the message " prohibited team"
Exactly describe the source of the problem, and not just give general phrases like " syntax error ".
Giving constructive advice on how to fix the problem. For example, instead of reporting that the product " not available", your error message should either tell you when the item is back in stock or prompt users to set up a notification message to be sent to them when the item is back in stock.

The most common mistake on the Web is 404 - violates most of these rules. I recommend that you write your own 404 error message instead of relying on the server's mean "page not found".

New rules

The complexity of working with web pages has led to another rule that was not required in the old days. In the DOS interface, users would type a command and an error message would appear in next line on the screen. In modern graphical shells When the user selects an erroneous command, the error message is displayed in a large dialog box in the center of the screen and does not disappear until the user accepts it. However, in Web messages Error messages are often hidden in the text of the page, which is why we deduce the following rule: the error message should be:

Visible and very noticeable, both regarding the message itself and the place where the user must correct the error.

I have often noticed how users make a mistake on a web form, submit the form, and get the same form on the screen again without any indication of what is wrong with it. Often there will be a small error message at the top of the page, but since users look first at what they are working with on the page (that is, the form fields), they usually do not notice this message.

Likewise, it would be incorrect to indicate an error message only in red. This violates one of the oldest and simplest rules of creating technology accessible to users with health problems: never use only color in an interface to indicate system status; always supplement it with some other signals that people with problems in color perception can see.

Here are a few more rules that will help mitigate the unpleasant situation that the user finds himself in when making an error:

Save as much as possible from the work done by the user. Allow users to correct an error in their action rather than asking them to start over. For example, when displaying search results to him, show the search field there and display those in it keywords, which the user was looking for, so that he could correct them and improve the result. If the search does not return any results, give the user the ability to expand the search with one click.
Cut down on work to correct the error. If possible, try to have the system guess the correct action and prompt the user to select it right action from a small list of options. For example, instead of just writing " the name of the city does not correspond to it postal code ", allow the user to click a button and select the city corresponding to their zip code from a list.

User training

And finally, you probably already know Nielsen's First Computer Documentation Law: people don't read it. This law is even stronger for websites, where users actually avoid reading anything that is not essential to their task. Click on the "Help" link? No way.

Users read system documentation only when they have a problem (this is the Second Law). They read it especially carefully when they want to correct an erroneous action. In this case, you can use error messages as training material, and impart this knowledge in small portions. Naturally, error messages should be short and to the point, as is all website content. However, error messages can still give people nuggets of information about how the system works and suggest how best to work with it. And to end this topic, the Web introduces one more rule:

Hypertext links can be used to link a brief error message to additional material or an explanation of the problem. (Just be careful not to overdo it).

Everyone makes mistakes sometimes, it's inevitable: that's what error messages are for. However, many companies pay little attention to this interface element, which angers and scares away users.

Error messages can be incomprehensible and generally extremely unpleasant to the eye. Surely at least once you tried to register an account on the Internet and received a result like this:

“Help: How to create a password correctly?”

Things like this make you give up everything and stop further attempts. How can you design error messages to improve user experience, usability, and conversion?

Mixed messages

The worst thing is the mixed messages that don't answer the question: "What's wrong here?" Here's what the Amazon page looks like when, for some reason, it doesn't accept a promo code:

"The promotional code entered cannot be used for this purchase." Why?!

Any problems, including error messages, stimulate the production of the hormone cortisol, a well-known biomarker of stress. The cortisol surge can develop into anxiety, and when the user becomes confused, they give up:

Graph of productivity versus stress level, from left to right: calm state, “beneficial” stress, distress (harmful to health)

Sometimes the damage isn't just low conversions—error messages can drive people away from your brand. Investing in a better user experience includes both short-term efforts (increasing conversions) and long-term efforts (user retention, brand loyalty, word of mouth and so on).

While error reporting may seem like a weak topic compared to optimization or gamification, you can greatly improve your user experience simply by avoiding a few common problems.

Have you ever booked a flight with Spirit Airlines? To put it mildly, this is not an example of better experience interactions and error messages on this site are also not up to par.

If you deliberately mix everything up (as if the form is being filled out by a person who is far from the Internet), you will get the following result:

“The “request” field must be filled in”

So, you forgot to indicate whether you are “Mr.” or “Mrs.” After the fix, another error appears:

Is there something wrong with the email? Forgotten.com, but it's easy to fix:

Now what's the matter? You seem to have the same error in the email confirmation window. It would be nice if you were informed about this right away when the first address was entered:

“The email address you entered is already in use by a FreeSpirit user. Use a different address"

Now it turns out that someone has already created an account with that email address. It would be nice if it were possible to restore access if this address is still yours. It would also be possible to leave the passwords already entered.

Not all shapes look so sad, but many of them do. common problems. Avoid them and you'll be ahead. Let's look at everything in order.

Problem #1: Ambiguity

Your error messages should make it clear what exactly is wrong. Ever received messages like this?

"Your email could not be sent"

Why? How should the user understand this?

The Bitly service is simply boring with messages like this that don’t specifically explain what’s wrong. Username? Password? Both? Help the person understand where he went wrong:

"No, try again"

This is a fairly common problem.

It's nice when errors in the form are clearly highlighted in relation to other, correctly filled in fields. For example, Meetup.com always shows exactly where the inaccuracy or problem occurred and what to do about it:

“Sorry, there was an error. Error details are highlighted in color below"

The main thing is not to force the user to puzzle over your form. Tell us why the error occurred, where it appeared, and how to fix it. Increase clarity.

Problem #2: Condescending tone/blaming the user

What you definitely shouldn't do is try to scare the user with the idea that the error is much worse than it actually is. You don't want to force potential client feel stupid or guilty.

Simply saying that there is a problem is enough. Even if this was the user’s fault, do not blame him under any circumstances. Here's one exaggerated (though common) example:

“We have already warned you three times that this file does not exist. Don't do that again"

Also, you should not use words with a negative connotation - they make the user think that the situation is worse than it actually is. Here are a few words to avoid:

"Oops, something went wrong" (Oops)
"There are errors in this form" (Error)
"Form submission failed" (Failed)
"There was a problem creating your profile" (Problem)
“The fields are filled in incorrectly” (Wrong)
“3 errors make it impossible to save given user"(Impossible)

Problem #3: Incorrect placement of error messages

Here's what UXMovement writes in its article:

“Mistake lists increase stress. When a user sees many errors at once, it’s easier for him to drop everything and forget than to fix it.”

What's more intimidating than seeing something like this just as you're about to hit send?

“Errors that were found when filling out, please correct them and confirm the form again”

Line-by-line confirmation can solve this problem because the user receives instant feedback and learns how to avoid making mistakes later. However, even if you don't want to implement line-by-line data validation, at least make it clear to the user where exactly the error occurred.

The location of error messages is not something that people usually think about, but it is important nonetheless. Here's what Usabilla has to say about it:

“Ultimately, the placement of your error messages becomes very important, because the right place is the key to a positive user experience. Logically placing the error not only saves you time on explanations, but also allows the user to quickly find the source of the problem and fix it.”

In the following example, the errors are better placed than when they were all together, but it is still unclear where the specific error occurred (for example, the error "The 'name' field cannot be empty" is between the first and last name fields, creating ambiguity):

The user must understand exactly where he made a mistake. So, in Netflix, the error text is located above the form, and the fields are simply highlighted in red. It's easy to miss an error message like this or not find the field you're looking for:

"Your password must be between 4 and 60 characters"

Problem #4: Unclear Expectations

This is very common mistake, so it’s important not to do it. Even if your message is not negative, is in the right place, and makes it clear what exactly is wrong, you will still anger users by not telling them what they should do.

Many error messages are unclear next step. Like the Spirit Airlines example, they could have provided several options to regain access to your account or asked, “Did you already have an account? Log in here." Instead, they simply report that your email is already in use.

“This email is already in use, please enter a different one”

An excellent error message that educates the user and helps them fix it comes from MailChimp:

“Sorry, we didn’t find an account with that name. Can I help you recover your username?"

If your form does not allow for flexible filling of fields with certain data (for example, phone numbers, zip codes, etc.), it is good to make it clear to the user exactly how he should enter data. You can report this using text in a small font directly below the field.

Microtext is “small prompts aimed at educating and instructing users.” It helps you avoid mistakes before they happen.

So, information on how to enter an address associated with credit card, could significantly reduce the number of questions when filling out a form, saving the user time and increasing your profits from improved conversion:

“Make sure you are entering the address associated with your credit card.”

Here's another example where text with instructions would help:

"Please enter a numeric value"

Peep Laja was trying to fill out a form on a website to get a link to an event. However, this resulted in him returning to the first page containing a large red message, “There is a problem with your subscription,” full of uncertainty.

The point was that he entered the word “Several” in the “Number of Guests” field (reasonable, given that it is quite difficult to calculate the number of guests for an event), but the form implied an exact number. Of course, there was no mention of this before he hit send: microtext would have been very useful in this situation.
(Although in this particular example there are many more problems than just a lack of explanation).

Good and bad error messages have vastly different results in user behavior. Here's a funny story from experience professional Jennifer Aldrich:

“Once in our laboratory two users were working next to each other - one in the program third party manufacturer, the second one tested our product. It so happened that they both made a mistake at the same time. The third-party program showed a huge red cross and the word “Error” written in caps lock, followed by an incomprehensible long explanation. The user sighed, minimized the browser, and turned around in his chair as if the monitor might attack him.

A person testing our product received a message like: “Something strange happened, we apologize. Please refresh the page and try again." The error code was listed in small print below the message, and there was also an option to expand it to see more details if desired. The user smiled, refreshed the page and continued working.”

It's impossible to come up with perfect text, location, color, time frame, and so on for error messages that should be present on your site.

However, you can use existing design templates and best practics. Do some usability research and analytics if you want to learn even more about creating the perfect error message and see if it can be applied to your resource.

The best examples of error messages, tested over the years

The Nielsen Norman Group proposed the following error reporting best practices back in 2001—and they still work:

A visible and noticeable message regarding both the error text itself and the element that needs to be corrected.
Save the energy of your users. Ask them to correct only the error itself—don’t force them to fill out the form again. When displaying search results, show a window with the original search query to simplify the process. If no matches are found, the user will only need to expand the already prepared search query.
Reduce bug fixing work. If possible, suggest the user possible correct options and ask to choose the one you need from the list. For example, instead of simply writing “City and zip code do not match,” allow the user to click on a button with the name of the city that matches the entered zip code.

UXMas have a helpful rule regarding error reporting that they call the “4Hs.” According to this rule, the error message should be:

Human
Helpful
Humorous
Simple (Humble)

1. Human

UXMas say rule number one is to "make sure the error message sounds like it's a conversation between two people." Here's an example of a bad error message that doesn't satisfy this rule:

It sounds like it was written by a robot. You should also avoid jargon, too technical language(of course, if your audience is not technical people). For example, what does this mean?

2. Useful

Three factors make an error message useful:

Is it noticeable?
Does it explain what went wrong?
Does it help the user fix the error?

We've talked about this before: post your posts intuitively. in clear places, make them bright and noticeable enough, clearly explain the essence of the problem and offer a solution.

3. Funny

According to UXMas, “a trusting and light tone of the message makes the user feel like they are on your side - especially if it is consistent with your brand policy.”

However, humor should be used in the context of its audience: it can either confuse the user further or have the opposite effect. Pages with 404 error - perfect place for applications of light humor (and strategic redirection to another page).

“Ooh! Winston dresses very cool. However, now he appears to be wearing something inappropriate (just like the page you're looking for). Let's help him choose something else! "

Yahoo! Here's a great example of using humor when submitting a form:

“Are you really from the future??”

4. Simple

It's easy: don't blame the user. We've talked about this before - take the blame, apologize and offer a solution to the problem.

How about line-by-line checking?

Line-by-line checking is a masterful way to find, prevent and correct errors in real time. Instead of waiting for the form to complete, you instantly inform the user that something was filled out incorrectly:

“You can use letters, numbers and dots.”
"Please enter between 6 and 30 characters"

There are results of quite serious studies on line-by-line verification. Luke Wroblewski tested it in 2009 against a check after clicking the submit button. Although there were not many examples of samples during the study, the results for line-by-line testing were as follows:

22% more successfully completed forms,
22% fewer errors,
User satisfaction increased by 31%,
Filling time reduced by 42%,
The number of gaze fixations decreased by 47%.

Getting 22% more people to successfully complete a form is worth it, as is creating a more engaging user experience.

A good example of a line-by-line check of the booking.com website:

“We will send you a booking confirmation and a guide to Tallinn!”

How to track errors using Google Analytics

Tim Leighton-Boyce of CXFocus recently blogged about one of his favorite GA reports:

“One of my favorite reports is a standard report that many people don’t pay attention to: Conversion > Goals > Path Back to Goal. I use it for bug tracking.

This requires the ability to create an error target, which is not always possible for a site. However, if you can create such a goal, then the “Return Path to the Goal” will become great tool. It works well in cases where it is impossible to predict the steps that led to the error, unlike the ordering funnel. In fact, the steps leading to the goal are in this case and that is what we are trying to find":

Way back to the goal

You can also use scripts to track JavaScript errors on your page and then add them to event tracking in Google Analytics. Search

Engine Watch explains how to set up event tracking to detect errors in form completion:

“Set your form to track events, where each event represents a specific form field. The category should determine which form contains the most errors, and the label should be dynamic, pulling up the definition of the rule that caused the error and the entered value that violates that rule, separated by, for example, a "|" character.

The above may require developer assistance. However, having set all the settings, you will have access to an event report, in which errors when filling out your form are counted and sorted. You can understand the cause of the error by analyzing the values entered by users. As a result, you will decide to either simplify the logic for checking the value in the field, or add explanatory text that will reduce the number of errors that affect conversion.

Instead of a conclusion

Working on error messages is aimed at reducing user irritation when filling out the form. If a user is stressed (that is, their body produces the hormone cortisol), you risk losing them and forcing them to leave for your competitors.

Conventional wisdom says that good bug reports should be polite, accurate, and constructive. With the advent of the Web, several more requirements have been added to these requirements: make the error message clearly visible; in case of an error, the user does not have to spend a lot of time correcting it; Train users as you go.

The rules for creating effective error messages have remained the same for 20 years. A good error message should:

Clearly indicate that something is wrong. The worst error message is one that was not created. If users make a mistake and don't get any response from the system, that's the worst thing for them. For example, an email application has several situations where an indication of an error that occurred would be clearly useful. Let's say you sent an email message that was successfully swallowed by the system, but never reached the recipient. Another example? You say in the letter that you are attaching a file to it, but you simply forgot to do so. This is where that stupid MS Office paperclip would have a job: "Looks like you wanted to attach a file to your message, but didn't. Would you like to do that?"

Be written in human language, and not using mysterious codes and abbreviations like "a type 2 error occurred."

Be polite and don't blame users for being stupid or doing something wrong, such as in the "forbidden command" message.

Accurately describe the source of the problem, rather than just throwing out general phrases like "syntax error."

Give constructive advice on how to fix the problem. For example, instead of saying that an item is "out of stock," your error message should either tell you when the item will be in stock or prompt users to set up a notification message to be sent to them when the item is back in stock.

The most common error on the Web, 404, violates most of these rules. I recommend that you write your own 404 error message instead of relying on the server's mean "page not found" phrase.

New rules

The complexity of working with web pages has led to another rule that was not required in the old days. In the DOS interface, users would type a command and an error message would appear on the next line on the screen. In modern graphical environments, when the user selects an erroneous command, the error message is displayed in a large dialog box in the center of the screen, and the error message does not disappear until the user accepts it. However, on the Web, error messages are often hidden in the text of the page, which is why we make the following rule: the error message should be:

Visible and very noticeable, both regarding the message itself and the place where the user must correct the error.

Here are a few more rules that will help mitigate the unpleasant situation that the user finds himself in when making an error:

Retain as much of the user's work as possible. Allow users to correct an error in their action rather than asking them to start over. For example, when displaying search results, show the search field there and display the keywords that the user was looking for so that he can correct them and improve the result. If the search does not return any results, give the user the ability to expand the search with one click.

Reduce the work required to fix the error. If possible, try to have the system guess the correct action and prompt the user to select that correct action from a small list of options. For example, instead of simply writing "the city name does not match its zip code," give the user the opportunity to click a button and select the city that matches their zip code from a list.

User training

Finally, you probably already know Nielsen's First Law of Computer Documentation: People don't read it. This law is even stronger for websites, where users actually avoid reading anything that is not essential to their task. Click on the "Help" link? No way.

Back

Conventional wisdom says that good bug reports should be polite, accurate, and constructive.

The rules for creating effective error messages have remained the same for 20 years. A good error message should:

1. Explicitly indicate that something is wrong. The worst error message is one that was not created. If users make a mistake and don't get any response from the system, that's the worst thing for them. For example, an email application has several situations where an indication of an error that occurred would be clearly useful.

Let's say you sent an email message that was successfully swallowed by the system, but never reached the recipient. Another example? You say in the letter that you are attaching a file to it, but you simply forgot to do so. This is where that stupid MS Office paperclip would have a job: "Looks like you wanted to attach a file to your message, but didn't. Would you like to do that?"

2. Be written in human language, not using mysterious codes and abbreviations like “a type 2 error has occurred.”

3. Be polite and do not blame users for being so stupid or for doing something wrong, such as in the “forbidden command” message.

4. Accurately describe the source of the problem, and not just give general phrases like “syntax error.”

5. Give constructive advice on how to fix the problem. For example, instead of saying that an item is "out of stock," your error message should either tell you when the item will be in stock or prompt users to set up a notification message to be sent to them when the item is back in stock.

The most common error on the Web, 404, violates most of these rules. I recommend that you write your own 404 error message instead of relying on the server's mean "page not found" phrase.

New rules

In modern graphical environments, when the user selects an erroneous command, the error message is displayed in a large dialog box in the center of the screen, and the error message does not disappear until the user accepts it. However, on the Web, error messages are often hidden in the text of the page, which is why we deduce the following rule - the error message should be:

Visible and very noticeable, both regarding the message itself and the place where the user must correct the error.

Here are a few more rules that will help mitigate the unpleasant situation that the user finds himself in when making an error:

Reduce the work required to fix the error. If possible, try to have the system guess the correct action and prompt the user to select that correct action from a small list of options. For example, instead of simply writing "the city name does not match its zip code," give the user the option to click a button and select the city that matches their zip code from a list.

User training

And finally, you probably already know Nielsen's First Law of Computer Documentation: People don't read it. This law is even stronger for websites, where users actually avoid reading anything that is not essential to their task. Click on the "Help" link? No way.

Naturally, error messages should be short and to the point, as is all website content. However, error messages can still give people nuggets of information about how the system works and suggest how best to work with it. And to end this topic, the Web introduces one more rule: