Sii Poland

SII UKRAINE

SII SWEDEN

  • Trainings
  • Career
Join us Contact us
Back

Sii Poland

SII UKRAINE

SII SWEDEN

Back

21.02.2025

Error handling – how to create clear messages

21.02.2025

Komunikaty o błędach – jak tworzyć zrozumiałe treści

In digital products, error and failure messages are integral to the user’s interaction with the software. This content can significantly influence the feeling of a given application. Therefore, understanding how to create messages is crucial not only for designers but also for developers.

When a user encounters a problem, their workflow is interrupted. In this situation, it is worth showing that the problem is easy to solve. A clear error message can significantly reduce the level of frustration. If we help users understand what happened and offer specific steps to fix the issue, users will not waste time and focus on their goal. We also want the user to know that solving problems is simple and fast. We will improve the user’s interaction with the interface by providing effective messages.

Content that shows the product creators care about the user and their experience builds a relationship. If users see that their problems are taken seriously, they are more likely to return to the service. A well-thought-out product translates to positive reviews.

In this article, I will try to present strategies and best practices that can help mitigate the negative impact of errors on users.

Prevention is better than cure

The best approach is to minimize the number of errors users might encounter. Prevention is more effective than reacting to problems, so it is worth investing time and resources during the design and testing stages.

Intuitive interfaces reduce the risk of user errors. Visuals, such as icons and labels, help users understand possible actions.

Consider the following elements during the design stage.

Onboarding

Users who are well-informed about how to use the application make fewer errors. Short guides, tutorials, and hints can significantly improve the system’s understanding and operation.

An example of an onboarding tooltip in Webflow shows how to start the first website project
Fig. 1 Example of onboarding tooltip in Webflow (source)

Constraints

Constraints help users enter only correct data and perform allowable actions, minimizing the number of errors they can make.

In the mBank app, the user can define a PIN using only the numeric keypad, which excludes the entry of non-numeric characters
Fig. 2 The mBank banking app allows user to enter only numbers when setting a PIN code (source)

Automatic suggestions and correction

Systems can automatically suggest phrases or correct minor errors. This is particularly useful and improves the user’s interaction with the digital product.

The website znanylekarz.pl offers auto-suggestions when typing phrases into the search bar
Fig. 3 Example of auto-suggestions in the search bar of the znanylekarz.pl website (source)

Preventing errors is extremely important, but it is impossible to completely eliminate the risk of their occurrence. Unfortunately, errors are an inevitable part of user interaction with software. It is important to adequately assist the user when they occur.

What does a clear error message mean?

The key to success is properly defining the problem. The user must understand what went wrong. The message should be concise but also contain all the necessary information to resolve the issue. Error messages are elements that users dislike. Improper text can ruin positive experiences.

A well-designed error message should include:

  • defining the problem,
  • why the problem occurred,
  • how the problem affects the user and their further actions,
  • how to solve the problem and what can be done to prevent it from happening.

Key principles for designing error messages

In the following section, you will find information on properly designing error messages.

On the left, the message " You entered incorrect password" blames the user. On the right, the recommended neutral version of the message is "Incorrect password. Please try again."
Fig. 4 Instead of blaming the user, choose a neutral message

Don’t blame the user

Blaming the user for an error can lead to even more frustration and discouragement. The message should be neutral and focused on resolving the issue. Remember to be polite and empathetic.

Also, remember not to attack users with all capitalized letters or exclamation marks. For example, if a user fills out a form and forgets to enter their email address, avoid using aggressive messages like “Field is required!” or ” FIELD IS REQUIRED. ” Try using a nicer message: “Please enter your email address.” Such a message is more understandable and helps the user focus on correcting the error without additional stress.

On the left, the message " You entered incorrect password" blames the user. On the right, the recommended neutral version of the message is "Incorrect password. Please try again."
Fig. 5 Do not attack users with Caps Lock

Be specific and to the point

Error messages should precisely inform the user about the problem. Too general messages do not give users enough information to take further steps. Avoid vague statements in favor of more detailed descriptions that help understand what went wrong.

On the left, the message "Oops! An error occurred." does not inform about the cause of the error. On the right, the recommended version of the message is " Message could not be sent. Please check your internet connection and try again."
Fig. 6. Provide clear information about the cause of the error and provide support

The first message is too general, so the user has no idea where the problem lies or what to do next. Use more detailed messages that provide clear guidance about the problem and the steps that can be taken to resolve it.

On the left, the message " An error occurred. Your changes could not be saved." On the right, the recommended version: " Your changes could not be saved. Please check your permissions and try again."
Fig. 7 Avoid too generic error messages. Try to provide the error cause and solution

Use plain language and avoid technical jargon

Write in an understandable way to the average user and avoid technical jargon. This is very important when designing messages that every user can understand. Do not use abbreviations or terms that are only familiar to developers.

Remember, plain language partially contributes to digital accessibility. Read more about simple language on the government website.

Messages should be written in plain and clear language. Whenever possible, avoid overly general statements and mysterious numbers, such as error 1020.

On the left, the message includes an error code and a general statement: " System Error(code #1020): Authentication issues." On the right, a proposed new message is: " Unable to sign-in: Incorrect username or password."
Fig. 8 If possible, avoid cryptic error codes (graphic based on uxmag)

If we must use an error code, we can include it in the message. But remember, explaining what this means to the user is important.

404: but that’s clear!

Also, when we encounter well-known error codes such as “Error 404: Page not found” or “Error 500: Internal server error,” we should remember that users have different levels of technological knowledge. It is best not to assume that everyone understands such codes.

Instead of: “Error 404: Page not found.”

Use: “We couldn’t find the page you were looking for. Check if the URL is correct, or return to the homepage.”

Instead of: “Error 500: Internal server error.”

Use: “There is a problem with our server. Please try again in a few minutes. If the problem persists, contact us at [email protected].” Our messages should be written so everyone can understand, regardless of their technical knowledge.

What if the target group has a narrow specialization and specific needs?

In applications dedicated to specialized groups of users, such as doctors, avoiding technical-specific terminology can be challenging. Users in these fields are often familiar with specific terms and expect to see them in the interface. However, ensure the terms fit the context and match the users’ level of expertise. Ensure that the messages use the common language used in a particular industry. Avoid abbreviations and terms that could be confusing. If we need to use specific terms, provide explanations or definitions where possible.

Let’s throw away negative words

Content should be as neutral as possible. Negative words and phrases can only worsen things, increasing the user’s irritation. Avoid negative terms such as “bad,” “critical,” or “unacceptable,” as well as jokes, slang, and abbreviations that can be misunderstood.

Instead of writing “Critical error!”. Describe the reason: “There was a problem with the operation. Please try again or contact technical support.”. Negative phrases are discouraging and can also make users feel guilty or incompetent.

On the left, the message "Critical error occurred." On the right, the recommended message is " We cannot continue the operation. Please try again in a few minutes or contact our support.".
Fig. 9 Avoid negative words like “error” or “critical”

Jokes and slang can be confusing and unprofessional. Instead, use clear and professional messages.

On the left, the message "Oops! Something went wrong. 
Our servers took a break." On the right, the recommended message is " There was a problem with our servers. Please try again in a few minutes.".
Fig. 10 Let’s keep our messaging professional. Using “Oops!” in such a situation does not inspire much trust. It makes it sound like we, as product creators are trivializing a situation that is not trivial. Instead, we should communicate to the user that we are serious about helping them find a solution, no matter the situation (graphic based on theuxgal)

Support users

Error messages should inform the user about the problem and suggest what the user can do to fix it. This way, we help the user get back to work quickly.

This message appears in Google Chrome when there is no Internet connection. It provides user support by listing the steps that can be taken.
Fig. 11 The message in the Google Chrome browser contains several tips on how to fix the Internet connection error (source)

If the error message is unclear or the problem is not resolved, users should be able to contact technical support.

This is a Microsoft Office message that appears when the program launches incorrectly. The message provides additional instructions on how to fix the problem and a link to additional online help.
Fig. 12 Microsoft Office message indicates additional online help (source)

Messages should be visible

Error messages should be easy to spot and read. Using distinctive colors and placing them appropriately on the page helps to convey information effectively. Use colors that stand out clearly from the rest of the interface. Red and orange are commonly used to highlight errors because they attract attention and are easy to notice. To make the message readable, provide adequate contrast between the text and the background. For example, red text on a white background or white text on a red background.

Place error messages where the user is sure to notice them. Ideally, they should be near the element that caused the error. A bad example would be placing the error message at the bottom of the page, where the user can easily miss it. Ideally, the message should appear directly next to the form field where the error occurred.

Example of placing a message below the line that is being edited. However, this method requires additional space below the line that is affected
Fig. 13 Example of placing a message below the line that is being edited. However, this method requires additional space below the line that is affected (source)

For global errors, it is a good idea to place the message in a fixed location, such as at the top of the page, where it will be visible regardless of scrolling. Instead of displaying the error message randomly on the page, it is better to display it in the top bar or in the middle of the screen.

What if red is the primary or secondary color in the visual identity?

If red is the primary color in the visual identity, we must find another way to make error messages stand out and readable. We have to remember not to break the consistency of the design.

We can add complementary colors, such as yellow or orange, in this situation. Another solution is to use warning icons that indicate an error.

An example of this approach is the Crane app, which uses orange to highlight errors. Red is a secondary color, so a red error, in this case, would not stand out enough from the surrounding UI and could be misread.

Crane application uses red as the secondary color to highlight selected elements
Fig. 14 Crane application uses red as the secondary color to highlight selected elements (source)
The Crane app uses orange as an alternate color for errors. Orange is associated with a warning, and an exclamation mark icon is also used
Fig. 15 The Crane app uses orange as an alternate color for errors. Orange is associated with a warning, and an exclamation mark icon is also used (source)

Display time

An important aspect is the display time of the message. Error information should remain on the screen long enough for the user to read it calmly. The messages should stay visible for serious errors until the problem is resolved.

Avoid displaying errors prematurely

Presenting errors too early can cause additional frustration and confusion for users. To avoid this, it is worth including strategies such as:

  • real-time validation,
  • delayed message display,
  • clear hints.

Introducing techniques for gradually revealing information (progressive disclosure) effectively minimizes negative experiences related to errors. It involves providing users with only the information they need at that moment. Regular interface testing with real users helps identify moments when errors are displayed prematurely.

Avoid displaying error messages until the user has finished filling out a particular field and moved on to the next one. Showing error messages during typing can feel like an unjustified reprimand.

Fig. 15 LG's website displays a premature error message regarding the postal code format when the user starts typing in the numbers. The error message persists until 5 characters have been entered. A better solution would be to validate the field as the user moves on to the next form field
Fig. 16 LG’s website displays a premature error message regarding the postal code format when the user starts typing in the numbers. The error message persists until 5 characters have been entered. A better solution would be to validate the field as the user moves on to the next form field (source)

Be consistent

We should use the same terms and phrases throughout our app to avoid confusion. For example, if we use the term “password” in one place, we should not change it to “passkey” in another place. Keeping the terminology consistent helps users quickly understand a message without thinking about its meaning.

On the left, for the "Password" field, the message states, "Incorrect passkey. Please try again." On the right, it says, "Incorrect password. Please try again."
Fig. 17 Inconsistent terminology is confusing

Let’s also maintain consistent text formatting in error messages. This includes font size, colors, bold, italics, etc. Consistent formatting makes messages easier to recognize and understand. Maintaining consistent terminology and visual layout also reinforces the application’s professional and well-thought-out image.

Testing

Observe how users respond to messages. Review and update error messages regularly based on new information and feedback. This process should continue throughout the product lifecycle to adapt messages to changing user needs and expectations.

Not only errors

In some situations, the user needs confirmation that a given operation has been completed successfully and everything went according to plan. This is especially true for processes where users may have doubts about the status of the performed action, such as placing orders or sending forms.

The status "Message sent" appears after sending the message.
Fig. 18 Success state when sending the form (graphic based on Newsletter przeprojektowani.pl (author of Newsletter – Rafał Wróbel))

The role of humor

Humor in error messages is a controversial topic with many opinions. Depending on the context and how it is used, humor can have both positive and negative effects.

When used appropriately, humor can help build a positive impression of a brand and make interactions with the app more enjoyable. Remember that different people can interpret humor in different ways. What may be funny to one person may be inappropriate or confusing to another.

When to use humor in error messages?

Humor can be used in less critical situations where the error does not significantly impact the application’s functionality or security. Examples include messages about minor issues, such as a temporary lack of internet connection or a lack of content at a given link.

Below is a message from the Twitch platform. The message is consistent with the brand image, a little humorous but not overly cute or annoying.

If the content is not available under the link on the Twitch platform, the text states, "Sorry. Unless you've got a time machine, that content is unavailable."
Fig. 19 The Twitch error message creatively informs about the lack of content at a given link (source)

If a brand is known for its relaxed and friendly tone, humor can be consistent with its image and well-received by users. Before introducing humorous error messages, test them on the target group and gather feedback to ensure they are well-received and understood.

Checklist

When designing messages, keeping a sheet or other type of document in which we will document texts and changes is worth it. It is worth numbering errors, which makes it easier to navigate through the application content. The ideal solution is to create a checklist that we can look at while writing messages. Completing best practices and sharing them with the team will be valuable and make work easier.

Here is an example checklist:

  1. Describe the problem in simple and understandable language. Use full sentences.
  2. Explain what caused the problem.
  3. Avoid overly general statements.
  4. Explain the solution to the problem. If it requires several steps, provide a link to a help page with detailed instructions.
  5. Offer support or contact technical support.
  6. Avoid technical terminology and write in the user’s voice.
  7. Use friendly and understandable messages.
  8. Do not blame the user for the error. Avoid text written in capital letters and exclamation marks.
  9. Check if the message is easy to spot.
  10. Design content consistent with brand values ​​and tailored to the target group. Remember the appropriate style and form of communication.
  11. Check if the messages in the product are consistent not only in terms of content but also visually.

It is worth making our list, which we will use for the needs of a given client, depending on the needs. We should also enrich the list with examples of texts used in our product.

praca EN k 1 - Error handling – how to create clear messages

Summary

In this article, we’ve discussed a few rules for creating error messages. Properly designed content informs about the problem, guides the user to the solution, and minimizes frustration. Effective error messages can also strengthen positive relationships between users and the brand.

We should also remember to integrate texts with the user interface as early as possible. This allows for the creation of a consistent and integrated experience. When texts are designed simultaneously with UI elements, their formatting and display can be better adjusted.

Another important aspect is testing messages in a real environment and regularly updating them based on user feedback. This allows us to adapt our content to the needs and expectations of the audience.

Bibliography

  1. Error-Message Guidelines (nngroup.com)
  2. Hostile Patterns in Error Messages (nngroup.com)
  3. The ultimate error message UX writing guide (plus examples) (theuxgal.com)
  4. Prosty język – Dostępność cyfrowa – Portal Gov.pl (www.gov.pl)
  5. Poznaj 10 zasad prostego języka w Centralnym Ośrodku Informatyki (www.gov.pl)
  6. Book „UX writing. Moc języka w produktach cyfrowych”, Wojciech Aleksander
  7. How to Write Error Messages: Faster, Stronger, Better – Technical Writing Tools (ihearttechnicalwriting.com)
  8. Tips for UX Writing – UX Magazine
  9. How to Design Inline Editing and Validation in Tables – UX Design World (uxdworld.com)
5/5
Rating
5/5
Avatar

About the author

Aneta Łukowska

UX/UI Designer with a great passion for UX writing. She started her professional career as a Technical Writer, designing content for various audiences. Since mid-2021, she has been working at Sii on projects in the medical industry. She collaborated with interdisciplinary teams to create solutions that meet both user needs and business goals. She tries to spend her free time outdoors and loves walking, cycling, and photographing nature

All articles written by the author

Leave a comment

Your email address will not be published. Required fields are marked *

You might also like

Join our team

See all job offers

Show results
Join us Contact us

Ta treść jest dostępna tylko w jednej wersji językowej.
Nastąpi przekierowanie do strony głównej.

Czy chcesz opuścić tę stronę?