We are a team of young professionals striving to deliver best valued products and services to our customers.

 

follow us

 > Web Development  > How to Write Good Error Messages

How to Write Good Error Messages

In our lives, mistakes are unavoidable. Same when it goes to a website, no matter how good is the design, errors are unavoidable too. A bad error message could be frustrating to the users and make them have a poor user experience.

So, how to design a good error message that can increase the speed of use and users’ subjective satisfaction? In this article, we’ll show you a guideline on how to write a good error message.

Be Specific and Not Ambiguous

Error messages should be written in a clear and simple language to understand. An unclear error message would make users confusing, not knowing the problem and solution.

Users should be told what happened, why it happened and what is the solution to fix the problem as they cannot be expected to know how to fix the problem by themselves. An error message that does not offer any clarity will give users a bad experience of the website.Thus, correct guidance is necessary to guide the users on how to correct the issue, to keep the users engaged and willing to make the corrections.

Keep It Short and Simple

Error messages should only contain necessary information which are short and simple. People rarely read sentences word by word as long sentences make users unwilling to spend so much time on reading. What users want is to fix the error quickly and get back to their work as fast as possible.

The longer the sentences, the more likely users would not read the sentences. Hence, always make sure the error messages are short and concise. Stay on point but never compromise clarity.

Keep the details if it is relevant. Do not over communicate the problem in which messages should only contain the information required to help users to solve the issue. Keep in mind that your goal is to write an error message that is short and meaningful.

Do Not Use Technical Terms

When users face error messages especially during work, they must be very frustrating and their work progress will be affected. Thus, in their perspective, they only want to get rid of the problem and get their work back on track.

If an error message contains technical terms, they would only get more confused and frustrating. Most of the users are not interested in technical details of the problem. Even a tech-savvy user, it is still better not to include technical terms in the error messages.

If there is really a need to include techinical and complex details, then make it a simple way to guide users on how to fix the issue quickly. For instance, place them in a troubleshooting section.

Do Not Blame Users (Be Humble)

Instead of blaming users for the actions, use proper tone to convey the issues gracefully to the users and help them understand it.

Human tone and language play a tremendous impact on how users comprehend the message.  Sometimes, a generic error message can sound very technical to users and is phrased in a way that accuses the user of making an error. It is more effective to be understanding, friendly and speak the same language that makes users know you are human.

Bear in mind that you should always focus on the problem, not the user action that led to the problem. Developer’s responsibility is to inform users’ mistakes in a good way. One good way to incorporate a more human tone for more user-friendly error messages is to think about explaining it out loud to someone.

5. Give Users a Direction

A good error message consists of problem identification, cause of the problem and solution to the problem. An error message without any of these 3 parts is not considered as a good error message.

Once users know what causes the problem, they need the solution to fix the issue. Hence, an effective error message should provide enough information to guide the users how to get out of the situation. Apart from giving guidance to the users, the message can also direct the user to some other place or person from where he can get detailed help about the problem.

Do Not Explain the Meaning of Buttons

Some errors might need a Call To Action (CTA) button or link to fix the error. Some messages would even need a dismiss button.

Your buttons and links should always make sense if read in isolation. This is to help screen reader users navigating through interactive elements, and anyone scanning the page. 

However, there is no need to explain what the buttons do as users should understand what buttons will do by reading their labels.  For example, when you want to use “ok”, be sure to be clear to the user what they’re saying “Ok” to. This is because “Ok” can be used to dismiss a message or take an action.

Use Proper Timing and Placement

Timing and placement are important as they help give context. An error message should be placed closer to the area from where it belongs to so that users do not need to look here and there after reading the message that what it talks about.

An error message should also be visible and noticeable. For instance, a message appearing on a screen should display in the current view even if the user has scrolled the view to top or bottom.

When designing an error message, it has to consider timing and placement for all users. Some questions like “what triggers the message?”, “when does the message appear?”,” where does the message appear?” and “is it clear what it’s related to?” should be asked when designing the messages too.

Conclusion

It is good to avoid errors, but humans make mistakes too, am i right? So, what we can do is to minimize the errors and handle the error in a more helping way. Keep in mind that the error messages are not to blame the users’ mistakes but to help them to solve the errors. By following the guidelines stated above, there should be no problem in writing a good error message.

So, how to design a good error message that can increase the speed of use and users’ subjective satisfaction? In this article, we’ll show you a guideline on how to write a good error message.