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.<\/p>\n\n\n\n
In this article, I will try to present strategies and best practices that can help mitigate the negative impact of errors on users.<\/p>\n\n\n\n
Prevention is better than cure<\/strong><\/strong><\/h2>\n\n\n\nThe 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.<\/p>\n\n\n\n
Intuitive interfaces reduce the risk of user errors. Visuals, such as icons and labels, help users understand possible actions.<\/p>\n\n\n\n
Consider the following elements during the design stage.<\/strong><\/p>\n\n\n\nOnboarding<\/strong><\/h3>\n\n\n\nUsers 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.<\/p>\n\n\n\n![\"An](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image1-2-1024x467.png\")
Fig. 1 Example of onboarding tooltip in Webflow (source<\/a>)<\/figcaption><\/figure>\n\n\n\nConstraints<\/strong><\/strong><\/h3>\n\n\n\nConstraints help users enter only correct data and perform allowable actions, minimizing the number of errors they can make.<\/p>\n\n\n\n![\"In](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image2-1.png\")
Fig. 2 The mBank banking app allows user to enter only numbers when setting a PIN code (source<\/a>)<\/figcaption><\/figure>\n\n\n\nAutomatic suggestions and correction<\/strong><\/strong><\/h3>\n\n\n\nSystems can automatically suggest phrases or correct minor errors. This is particularly useful and improves the user’s interaction with the digital product.<\/p>\n\n\n\n![\"The](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image3-1-1024x398.png\")
Fig. 3 Example of auto-suggestions in the search bar of the znanylekarz.pl website (source<\/a>)<\/figcaption><\/figure>\n\n\n\nPreventing 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.<\/p>\n\n\n\n
What does a clear error message mean?<\/strong><\/strong><\/h2>\n\n\n\nThe 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.<\/p>\n\n\n\n
A well-designed error message should include<\/a>:<\/p>\n\n\n\n\n- defining the problem,<\/li>\n\n\n\n
- why the problem occurred,<\/li>\n\n\n\n
- how the problem affects the user and their further actions,<\/li>\n\n\n\n
- how to solve the problem and what can be done to prevent it from happening.<\/li>\n<\/ul>\n\n\n\n
Key principles for designing error messages<\/strong><\/strong><\/h2>\n\n\n\nIn the following section, you will find information on properly designing error messages.<\/p>\n\n\n\n![\"On](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image4-2-1024x337.png\")
Fig. 4 Instead of blaming the user, choose a neutral message<\/figcaption><\/figure>\n\n\n\nDon’t blame the user<\/strong><\/strong><\/h3>\n\n\n\nBlaming 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n![\"On](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image5-1-1024x337.png\")
Fig. 5 Do not attack users with Caps Lock<\/figcaption><\/figure>\n\n\n\nBe specific and to the point<\/strong><\/strong><\/h3>\n\n\n\nError 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.<\/p>\n\n\n\n![\"On](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image6-1.png\")
Fig. 6. Provide clear information about the cause of the error and provide support<\/figcaption><\/figure>\n\n\n\nThe 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.<\/p>\n\n\n\n![\"On](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image7-1.png\")
Fig. 7 Avoid too generic error messages. Try to provide the error cause and solution<\/figcaption><\/figure>\n\n\n\nUse plain language and avoid technical jargon<\/strong><\/strong><\/h3>\n\n\n\nWrite 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.<\/p>\n\n\n\n
Remember, plain language partially contributes to digital accessibility. Read more about simple language on the government website<\/a>.<\/p>\n\n\n\nMessages should be written in plain and clear language. Whenever possible, avoid overly general statements and mysterious numbers, such as error 1020.<\/p>\n\n\n\n![\"On](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image8-1.png\")
Fig. 8 If possible, avoid cryptic error codes (graphic based on uxmag<\/a>)<\/figcaption><\/figure>\n\n\n\nIf we must use an error code, we can include it in the message. But remember, explaining what this means to the user is important.<\/p>\n\n\n\n
404: but that’s clear!<\/strong><\/h3>\n\n\n\nAlso, 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.<\/p>\n\n\n\n
Instead of:<\/strong> “Error 404: Page not found.”<\/p>\n\n\n\nUse:<\/strong> “We couldn’t find the page you were looking for. Check if the URL is correct, or return to the homepage.”<\/p>\n\n\n\nInstead of:<\/strong> “Error 500: Internal server error.”<\/p>\n\n\n\nUse:<\/strong> “There is a problem with our server. Please try again in a few minutes. If the problem persists, contact us at support@example.com.” Our messages should be written so everyone can understand, regardless of their technical knowledge.<\/p>\n\n\n\nWhat if the target group has a narrow specialization and specific needs?<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n
Let’s throw away negative words<\/strong><\/strong><\/h2>\n\n\n\nContent 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n![\"On](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image9-2.png\")
Fig. 9 Avoid negative words like “error” or “critical”<\/figcaption><\/figure>\n\n\n\nJokes and slang can be confusing and unprofessional. Instead, use clear and professional messages.<\/p>\n\n\n\n![\"On](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image10-1.png\")
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<\/a>)<\/figcaption><\/figure>\n\n\n\nSupport users<\/strong><\/strong><\/h2>\n\n\n\nError 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.<\/p>\n\n\n\n![\"This](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image11-1.png\")
Fig. 11 The message in the Google Chrome browser contains several tips on how to fix the Internet connection error (source<\/a>)<\/figcaption><\/figure>\n\n\n\nIf the error message is unclear or the problem is not resolved, users should be able to contact technical support.<\/p>\n\n\n\n![\"This](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image12-2.png\")
Fig. 12 Microsoft Office message indicates additional online help (source<\/a>)<\/figcaption><\/figure>\n\n\n\nMessages should be visible<\/strong><\/strong><\/h2>\n\n\n\nError 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n![\"Example](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image13-1.png\")
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<\/a>)<\/figcaption><\/figure>\n\n\n\nFor 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.<\/p>\n\n\n\n
What if red is the primary or secondary color in the visual identity?<\/strong><\/strong><\/h3>\n\n\n\nIf 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.<\/p>\n\n\n\n
We can add complementary colors, such as yellow or orange, in this situation. Another solution is to use warning icons that indicate an error.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n![\"Crane](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image14-1024x755.png\")
Fig. 14 Crane application uses red as the secondary color to highlight selected elements (source<\/a>)<\/figcaption><\/figure>\n\n\n\n![\"The](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image15.png\")
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<\/a>)<\/figcaption><\/figure>\n\n\n\nDisplay time<\/strong><\/strong><\/h2>\n\n\n\nAn 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.<\/p>\n\n\n\n
Avoid displaying errors prematurely<\/strong><\/strong><\/h3>\n\n\n\nPresenting errors too early can cause additional frustration and confusion for users. To avoid this, it is worth including strategies such as:<\/p>\n\n\n\n
\n- real-time validation,<\/li>\n\n\n\n
- delayed message display,<\/li>\n\n\n\n
- clear hints.<\/li>\n<\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n![\"Fig.](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image16-1024x538.jpeg\")
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<\/a>)<\/figcaption><\/figure>\n\n\n\nBe consistent<\/strong><\/strong><\/h2>\n\n\n\nWe 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.<\/p>\n\n\n\n![\"On](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image17-1-1024x337.png\")
Fig. 17 <\/em>Inconsistent terminology is confusing<\/figcaption><\/figure>\n\n\n\nLet’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.<\/p>\n\n\n\n
Test<\/strong>ing<\/h3>\n\n\n\nObserve 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.<\/p>\n\n\n\n
Not only errors<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n![\"The](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image18-2.png\")
Fig. 18 Success state when sending the form (graphic based on Newsletter przeprojektowani.pl (author of Newsletter \u2013 Rafa\u0142 Wr\u00f3bel)<\/a>)<\/figcaption><\/figure>\n\n\n\nThe role of humor<\/strong><\/strong><\/h2>\n\n\n\nHumor 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
When to use humor in error messages?<\/strong><\/strong><\/h3>\n\n\n\nHumor 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n![\"If](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/image19-1.png\")
Fig. 19 The Twitch error message creatively informs about the lack of content at a given link (source<\/a>)<\/figcaption><\/figure>\n\n\n\nIf 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.<\/p>\n\n\n\n
Checklist<\/strong><\/h2>\n\n\n\nWhen 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.<\/p>\n\n\n\n
Here is an example checklist:<\/p>\n\n\n\n
\n- Describe the problem in simple and understandable language. Use full sentences.<\/li>\n\n\n\n
- Explain what caused the problem.<\/li>\n\n\n\n
- Avoid overly general statements.<\/li>\n\n\n\n
- Explain the solution to the problem. If it requires several steps, provide a link to a help page with detailed instructions.<\/li>\n\n\n\n
- Offer support or contact technical support.<\/li>\n\n\n\n
- Avoid technical terminology and write in the user’s voice.<\/li>\n\n\n\n
- Use friendly and understandable messages.<\/li>\n\n\n\n
- Do not blame the user for the error. Avoid text written in capital letters and exclamation marks.<\/li>\n\n\n\n
- Check if the message is easy to spot.<\/li>\n\n\n\n
- Design content consistent with brand values \u200b\u200band tailored to the target group. Remember the appropriate style and form of communication.<\/li>\n\n\n\n
- Check if the messages in the product are consistent not only in terms of content but also visually.<\/li>\n<\/ol>\n\n\n\n
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.<\/p>\n\n\n\n![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/02\/praca-EN-k-1.jpg\")
<\/a><\/figure>\n\n\n\nSummary<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Bibliogra<\/strong>phy<\/h2>\n\n\n\n\n- Error-Message Guidelines (nngroup.com)<\/a><\/li>\n\n\n\n
- Hostile Patterns in Error Messages (nngroup.com)<\/a><\/li>\n\n\n\n
- The ultimate error message UX writing guide (plus examples) (theuxgal.com)<\/a><\/li>\n\n\n\n
- Prosty j\u0119zyk – Dost\u0119pno\u015b\u0107 cyfrowa – Portal Gov.pl (www.gov.pl)<\/a><\/li>\n\n\n\n
- Poznaj 10 zasad prostego j\u0119zyka w Centralnym O\u015brodku Informatyki (www.gov.pl)<\/a><\/li>\n\n\n\n
- Book \u201eUX writing. Moc j\u0119zyka w produktach cyfrowych<\/a>\u201d, Wojciech Aleksander<\/li>\n\n\n\n
- How to Write Error Messages: Faster, Stronger, Better \u2013 Technical Writing Tools (ihearttechnicalwriting.com)<\/a><\/li>\n\n\n\n
- Tips for UX Writing – UX Magazine<\/a><\/li>\n\n\n\n
- How to Design Inline Editing and Validation in Tables – UX Design World (uxdworld.com)<\/a><\/li>\n<\/ol>\n\n\n
Onboarding<\/strong><\/h3>\n\n\n\nUsers 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.<\/p>\n\n\n\nFig. 1 Example of onboarding tooltip in Webflow (source<\/a>)<\/figcaption><\/figure>\n\n\n\nConstraints<\/strong><\/strong><\/h3>\n\n\n\nConstraints help users enter only correct data and perform allowable actions, minimizing the number of errors they can make.<\/p>\n\n\n\nFig. 2 The mBank banking app allows user to enter only numbers when setting a PIN code (source<\/a>)<\/figcaption><\/figure>\n\n\n\nAutomatic suggestions and correction<\/strong><\/strong><\/h3>\n\n\n\nSystems can automatically suggest phrases or correct minor errors. This is particularly useful and improves the user’s interaction with the digital product.<\/p>\n\n\n\nFig. 3 Example of auto-suggestions in the search bar of the znanylekarz.pl website (source<\/a>)<\/figcaption><\/figure>\n\n\n\nPreventing 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.<\/p>\n\n\n\n
What does a clear error message mean?<\/strong><\/strong><\/h2>\n\n\n\nThe 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.<\/p>\n\n\n\n
A well-designed error message should include<\/a>:<\/p>\n\n\n\n\n- defining the problem,<\/li>\n\n\n\n
- why the problem occurred,<\/li>\n\n\n\n
- how the problem affects the user and their further actions,<\/li>\n\n\n\n
- how to solve the problem and what can be done to prevent it from happening.<\/li>\n<\/ul>\n\n\n\n
Key principles for designing error messages<\/strong><\/strong><\/h2>\n\n\n\nIn the following section, you will find information on properly designing error messages.<\/p>\n\n\n\nFig. 4 Instead of blaming the user, choose a neutral message<\/figcaption><\/figure>\n\n\n\nDon’t blame the user<\/strong><\/strong><\/h3>\n\n\n\nBlaming 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 5 Do not attack users with Caps Lock<\/figcaption><\/figure>\n\n\n\nBe specific and to the point<\/strong><\/strong><\/h3>\n\n\n\nError 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.<\/p>\n\n\n\nFig. 6. Provide clear information about the cause of the error and provide support<\/figcaption><\/figure>\n\n\n\nThe 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.<\/p>\n\n\n\nFig. 7 Avoid too generic error messages. Try to provide the error cause and solution<\/figcaption><\/figure>\n\n\n\nUse plain language and avoid technical jargon<\/strong><\/strong><\/h3>\n\n\n\nWrite 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.<\/p>\n\n\n\n
Remember, plain language partially contributes to digital accessibility. Read more about simple language on the government website<\/a>.<\/p>\n\n\n\nMessages should be written in plain and clear language. Whenever possible, avoid overly general statements and mysterious numbers, such as error 1020.<\/p>\n\n\n\nFig. 8 If possible, avoid cryptic error codes (graphic based on uxmag<\/a>)<\/figcaption><\/figure>\n\n\n\nIf we must use an error code, we can include it in the message. But remember, explaining what this means to the user is important.<\/p>\n\n\n\n
404: but that’s clear!<\/strong><\/h3>\n\n\n\nAlso, 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.<\/p>\n\n\n\n
Instead of:<\/strong> “Error 404: Page not found.”<\/p>\n\n\n\nUse:<\/strong> “We couldn’t find the page you were looking for. Check if the URL is correct, or return to the homepage.”<\/p>\n\n\n\nInstead of:<\/strong> “Error 500: Internal server error.”<\/p>\n\n\n\nUse:<\/strong> “There is a problem with our server. Please try again in a few minutes. If the problem persists, contact us at support@example.com.” Our messages should be written so everyone can understand, regardless of their technical knowledge.<\/p>\n\n\n\nWhat if the target group has a narrow specialization and specific needs?<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n
Let’s throw away negative words<\/strong><\/strong><\/h2>\n\n\n\nContent 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 9 Avoid negative words like “error” or “critical”<\/figcaption><\/figure>\n\n\n\nJokes and slang can be confusing and unprofessional. Instead, use clear and professional messages.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nSupport users<\/strong><\/strong><\/h2>\n\n\n\nError 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.<\/p>\n\n\n\nFig. 11 The message in the Google Chrome browser contains several tips on how to fix the Internet connection error (source<\/a>)<\/figcaption><\/figure>\n\n\n\nIf the error message is unclear or the problem is not resolved, users should be able to contact technical support.<\/p>\n\n\n\nFig. 12 Microsoft Office message indicates additional online help (source<\/a>)<\/figcaption><\/figure>\n\n\n\nMessages should be visible<\/strong><\/strong><\/h2>\n\n\n\nError 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nFor 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.<\/p>\n\n\n\n
What if red is the primary or secondary color in the visual identity?<\/strong><\/strong><\/h3>\n\n\n\nIf 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.<\/p>\n\n\n\n
We can add complementary colors, such as yellow or orange, in this situation. Another solution is to use warning icons that indicate an error.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 14 Crane application uses red as the secondary color to highlight selected elements (source<\/a>)<\/figcaption><\/figure>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nDisplay time<\/strong><\/strong><\/h2>\n\n\n\nAn 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.<\/p>\n\n\n\n
Avoid displaying errors prematurely<\/strong><\/strong><\/h3>\n\n\n\nPresenting errors too early can cause additional frustration and confusion for users. To avoid this, it is worth including strategies such as:<\/p>\n\n\n\n
\n- real-time validation,<\/li>\n\n\n\n
- delayed message display,<\/li>\n\n\n\n
- clear hints.<\/li>\n<\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nBe consistent<\/strong><\/strong><\/h2>\n\n\n\nWe 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.<\/p>\n\n\n\nFig. 17 <\/em>Inconsistent terminology is confusing<\/figcaption><\/figure>\n\n\n\nLet’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.<\/p>\n\n\n\n
Test<\/strong>ing<\/h3>\n\n\n\nObserve 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.<\/p>\n\n\n\n
Not only errors<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\nFig. 18 Success state when sending the form (graphic based on Newsletter przeprojektowani.pl (author of Newsletter \u2013 Rafa\u0142 Wr\u00f3bel)<\/a>)<\/figcaption><\/figure>\n\n\n\nThe role of humor<\/strong><\/strong><\/h2>\n\n\n\nHumor 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
When to use humor in error messages?<\/strong><\/strong><\/h3>\n\n\n\nHumor 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 19 The Twitch error message creatively informs about the lack of content at a given link (source<\/a>)<\/figcaption><\/figure>\n\n\n\nIf 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.<\/p>\n\n\n\n
Checklist<\/strong><\/h2>\n\n\n\nWhen 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.<\/p>\n\n\n\n
Here is an example checklist:<\/p>\n\n\n\n
\n- Describe the problem in simple and understandable language. Use full sentences.<\/li>\n\n\n\n
- Explain what caused the problem.<\/li>\n\n\n\n
- Avoid overly general statements.<\/li>\n\n\n\n
- Explain the solution to the problem. If it requires several steps, provide a link to a help page with detailed instructions.<\/li>\n\n\n\n
- Offer support or contact technical support.<\/li>\n\n\n\n
- Avoid technical terminology and write in the user’s voice.<\/li>\n\n\n\n
- Use friendly and understandable messages.<\/li>\n\n\n\n
- Do not blame the user for the error. Avoid text written in capital letters and exclamation marks.<\/li>\n\n\n\n
- Check if the message is easy to spot.<\/li>\n\n\n\n
- Design content consistent with brand values \u200b\u200band tailored to the target group. Remember the appropriate style and form of communication.<\/li>\n\n\n\n
- Check if the messages in the product are consistent not only in terms of content but also visually.<\/li>\n<\/ol>\n\n\n\n
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.<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nSummary<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Bibliogra<\/strong>phy<\/h2>\n\n\n\n\n- Error-Message Guidelines (nngroup.com)<\/a><\/li>\n\n\n\n
- Hostile Patterns in Error Messages (nngroup.com)<\/a><\/li>\n\n\n\n
- The ultimate error message UX writing guide (plus examples) (theuxgal.com)<\/a><\/li>\n\n\n\n
- Prosty j\u0119zyk – Dost\u0119pno\u015b\u0107 cyfrowa – Portal Gov.pl (www.gov.pl)<\/a><\/li>\n\n\n\n
- Poznaj 10 zasad prostego j\u0119zyka w Centralnym O\u015brodku Informatyki (www.gov.pl)<\/a><\/li>\n\n\n\n
- Book \u201eUX writing. Moc j\u0119zyka w produktach cyfrowych<\/a>\u201d, Wojciech Aleksander<\/li>\n\n\n\n
- How to Write Error Messages: Faster, Stronger, Better \u2013 Technical Writing Tools (ihearttechnicalwriting.com)<\/a><\/li>\n\n\n\n
- Tips for UX Writing – UX Magazine<\/a><\/li>\n\n\n\n
- How to Design Inline Editing and Validation in Tables – UX Design World (uxdworld.com)<\/a><\/li>\n<\/ol>\n\n\n
Constraints<\/strong><\/strong><\/h3>\n\n\n\nConstraints help users enter only correct data and perform allowable actions, minimizing the number of errors they can make.<\/p>\n\n\n\nFig. 2 The mBank banking app allows user to enter only numbers when setting a PIN code (source<\/a>)<\/figcaption><\/figure>\n\n\n\nAutomatic suggestions and correction<\/strong><\/strong><\/h3>\n\n\n\nSystems can automatically suggest phrases or correct minor errors. This is particularly useful and improves the user’s interaction with the digital product.<\/p>\n\n\n\nFig. 3 Example of auto-suggestions in the search bar of the znanylekarz.pl website (source<\/a>)<\/figcaption><\/figure>\n\n\n\nPreventing 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.<\/p>\n\n\n\n
What does a clear error message mean?<\/strong><\/strong><\/h2>\n\n\n\nThe 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.<\/p>\n\n\n\n
A well-designed error message should include<\/a>:<\/p>\n\n\n\n\n- defining the problem,<\/li>\n\n\n\n
- why the problem occurred,<\/li>\n\n\n\n
- how the problem affects the user and their further actions,<\/li>\n\n\n\n
- how to solve the problem and what can be done to prevent it from happening.<\/li>\n<\/ul>\n\n\n\n
Key principles for designing error messages<\/strong><\/strong><\/h2>\n\n\n\nIn the following section, you will find information on properly designing error messages.<\/p>\n\n\n\nFig. 4 Instead of blaming the user, choose a neutral message<\/figcaption><\/figure>\n\n\n\nDon’t blame the user<\/strong><\/strong><\/h3>\n\n\n\nBlaming 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 5 Do not attack users with Caps Lock<\/figcaption><\/figure>\n\n\n\nBe specific and to the point<\/strong><\/strong><\/h3>\n\n\n\nError 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.<\/p>\n\n\n\nFig. 6. Provide clear information about the cause of the error and provide support<\/figcaption><\/figure>\n\n\n\nThe 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.<\/p>\n\n\n\nFig. 7 Avoid too generic error messages. Try to provide the error cause and solution<\/figcaption><\/figure>\n\n\n\nUse plain language and avoid technical jargon<\/strong><\/strong><\/h3>\n\n\n\nWrite 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.<\/p>\n\n\n\n
Remember, plain language partially contributes to digital accessibility. Read more about simple language on the government website<\/a>.<\/p>\n\n\n\nMessages should be written in plain and clear language. Whenever possible, avoid overly general statements and mysterious numbers, such as error 1020.<\/p>\n\n\n\nFig. 8 If possible, avoid cryptic error codes (graphic based on uxmag<\/a>)<\/figcaption><\/figure>\n\n\n\nIf we must use an error code, we can include it in the message. But remember, explaining what this means to the user is important.<\/p>\n\n\n\n
404: but that’s clear!<\/strong><\/h3>\n\n\n\nAlso, 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.<\/p>\n\n\n\n
Instead of:<\/strong> “Error 404: Page not found.”<\/p>\n\n\n\nUse:<\/strong> “We couldn’t find the page you were looking for. Check if the URL is correct, or return to the homepage.”<\/p>\n\n\n\nInstead of:<\/strong> “Error 500: Internal server error.”<\/p>\n\n\n\nUse:<\/strong> “There is a problem with our server. Please try again in a few minutes. If the problem persists, contact us at support@example.com.” Our messages should be written so everyone can understand, regardless of their technical knowledge.<\/p>\n\n\n\nWhat if the target group has a narrow specialization and specific needs?<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n
Let’s throw away negative words<\/strong><\/strong><\/h2>\n\n\n\nContent 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 9 Avoid negative words like “error” or “critical”<\/figcaption><\/figure>\n\n\n\nJokes and slang can be confusing and unprofessional. Instead, use clear and professional messages.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nSupport users<\/strong><\/strong><\/h2>\n\n\n\nError 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.<\/p>\n\n\n\nFig. 11 The message in the Google Chrome browser contains several tips on how to fix the Internet connection error (source<\/a>)<\/figcaption><\/figure>\n\n\n\nIf the error message is unclear or the problem is not resolved, users should be able to contact technical support.<\/p>\n\n\n\nFig. 12 Microsoft Office message indicates additional online help (source<\/a>)<\/figcaption><\/figure>\n\n\n\nMessages should be visible<\/strong><\/strong><\/h2>\n\n\n\nError 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nFor 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.<\/p>\n\n\n\n
What if red is the primary or secondary color in the visual identity?<\/strong><\/strong><\/h3>\n\n\n\nIf 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.<\/p>\n\n\n\n
We can add complementary colors, such as yellow or orange, in this situation. Another solution is to use warning icons that indicate an error.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 14 Crane application uses red as the secondary color to highlight selected elements (source<\/a>)<\/figcaption><\/figure>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nDisplay time<\/strong><\/strong><\/h2>\n\n\n\nAn 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.<\/p>\n\n\n\n
Avoid displaying errors prematurely<\/strong><\/strong><\/h3>\n\n\n\nPresenting errors too early can cause additional frustration and confusion for users. To avoid this, it is worth including strategies such as:<\/p>\n\n\n\n
\n- real-time validation,<\/li>\n\n\n\n
- delayed message display,<\/li>\n\n\n\n
- clear hints.<\/li>\n<\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nBe consistent<\/strong><\/strong><\/h2>\n\n\n\nWe 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.<\/p>\n\n\n\nFig. 17 <\/em>Inconsistent terminology is confusing<\/figcaption><\/figure>\n\n\n\nLet’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.<\/p>\n\n\n\n
Test<\/strong>ing<\/h3>\n\n\n\nObserve 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.<\/p>\n\n\n\n
Not only errors<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\nFig. 18 Success state when sending the form (graphic based on Newsletter przeprojektowani.pl (author of Newsletter \u2013 Rafa\u0142 Wr\u00f3bel)<\/a>)<\/figcaption><\/figure>\n\n\n\nThe role of humor<\/strong><\/strong><\/h2>\n\n\n\nHumor 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
When to use humor in error messages?<\/strong><\/strong><\/h3>\n\n\n\nHumor 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 19 The Twitch error message creatively informs about the lack of content at a given link (source<\/a>)<\/figcaption><\/figure>\n\n\n\nIf 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.<\/p>\n\n\n\n
Checklist<\/strong><\/h2>\n\n\n\nWhen 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.<\/p>\n\n\n\n
Here is an example checklist:<\/p>\n\n\n\n
\n- Describe the problem in simple and understandable language. Use full sentences.<\/li>\n\n\n\n
- Explain what caused the problem.<\/li>\n\n\n\n
- Avoid overly general statements.<\/li>\n\n\n\n
- Explain the solution to the problem. If it requires several steps, provide a link to a help page with detailed instructions.<\/li>\n\n\n\n
- Offer support or contact technical support.<\/li>\n\n\n\n
- Avoid technical terminology and write in the user’s voice.<\/li>\n\n\n\n
- Use friendly and understandable messages.<\/li>\n\n\n\n
- Do not blame the user for the error. Avoid text written in capital letters and exclamation marks.<\/li>\n\n\n\n
- Check if the message is easy to spot.<\/li>\n\n\n\n
- Design content consistent with brand values \u200b\u200band tailored to the target group. Remember the appropriate style and form of communication.<\/li>\n\n\n\n
- Check if the messages in the product are consistent not only in terms of content but also visually.<\/li>\n<\/ol>\n\n\n\n
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.<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nSummary<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Bibliogra<\/strong>phy<\/h2>\n\n\n\n\n- Error-Message Guidelines (nngroup.com)<\/a><\/li>\n\n\n\n
- Hostile Patterns in Error Messages (nngroup.com)<\/a><\/li>\n\n\n\n
- The ultimate error message UX writing guide (plus examples) (theuxgal.com)<\/a><\/li>\n\n\n\n
- Prosty j\u0119zyk – Dost\u0119pno\u015b\u0107 cyfrowa – Portal Gov.pl (www.gov.pl)<\/a><\/li>\n\n\n\n
- Poznaj 10 zasad prostego j\u0119zyka w Centralnym O\u015brodku Informatyki (www.gov.pl)<\/a><\/li>\n\n\n\n
- Book \u201eUX writing. Moc j\u0119zyka w produktach cyfrowych<\/a>\u201d, Wojciech Aleksander<\/li>\n\n\n\n
- How to Write Error Messages: Faster, Stronger, Better \u2013 Technical Writing Tools (ihearttechnicalwriting.com)<\/a><\/li>\n\n\n\n
- Tips for UX Writing – UX Magazine<\/a><\/li>\n\n\n\n
- How to Design Inline Editing and Validation in Tables – UX Design World (uxdworld.com)<\/a><\/li>\n<\/ol>\n\n\n
Automatic suggestions and correction<\/strong><\/strong><\/h3>\n\n\n\nSystems can automatically suggest phrases or correct minor errors. This is particularly useful and improves the user’s interaction with the digital product.<\/p>\n\n\n\nFig. 3 Example of auto-suggestions in the search bar of the znanylekarz.pl website (source<\/a>)<\/figcaption><\/figure>\n\n\n\nPreventing 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.<\/p>\n\n\n\n
What does a clear error message mean?<\/strong><\/strong><\/h2>\n\n\n\nThe 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.<\/p>\n\n\n\n
A well-designed error message should include<\/a>:<\/p>\n\n\n\n\n- defining the problem,<\/li>\n\n\n\n
- why the problem occurred,<\/li>\n\n\n\n
- how the problem affects the user and their further actions,<\/li>\n\n\n\n
- how to solve the problem and what can be done to prevent it from happening.<\/li>\n<\/ul>\n\n\n\n
Key principles for designing error messages<\/strong><\/strong><\/h2>\n\n\n\nIn the following section, you will find information on properly designing error messages.<\/p>\n\n\n\nFig. 4 Instead of blaming the user, choose a neutral message<\/figcaption><\/figure>\n\n\n\nDon’t blame the user<\/strong><\/strong><\/h3>\n\n\n\nBlaming 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 5 Do not attack users with Caps Lock<\/figcaption><\/figure>\n\n\n\nBe specific and to the point<\/strong><\/strong><\/h3>\n\n\n\nError 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.<\/p>\n\n\n\nFig. 6. Provide clear information about the cause of the error and provide support<\/figcaption><\/figure>\n\n\n\nThe 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.<\/p>\n\n\n\nFig. 7 Avoid too generic error messages. Try to provide the error cause and solution<\/figcaption><\/figure>\n\n\n\nUse plain language and avoid technical jargon<\/strong><\/strong><\/h3>\n\n\n\nWrite 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.<\/p>\n\n\n\n
Remember, plain language partially contributes to digital accessibility. Read more about simple language on the government website<\/a>.<\/p>\n\n\n\nMessages should be written in plain and clear language. Whenever possible, avoid overly general statements and mysterious numbers, such as error 1020.<\/p>\n\n\n\nFig. 8 If possible, avoid cryptic error codes (graphic based on uxmag<\/a>)<\/figcaption><\/figure>\n\n\n\nIf we must use an error code, we can include it in the message. But remember, explaining what this means to the user is important.<\/p>\n\n\n\n
404: but that’s clear!<\/strong><\/h3>\n\n\n\nAlso, 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.<\/p>\n\n\n\n
Instead of:<\/strong> “Error 404: Page not found.”<\/p>\n\n\n\nUse:<\/strong> “We couldn’t find the page you were looking for. Check if the URL is correct, or return to the homepage.”<\/p>\n\n\n\nInstead of:<\/strong> “Error 500: Internal server error.”<\/p>\n\n\n\nUse:<\/strong> “There is a problem with our server. Please try again in a few minutes. If the problem persists, contact us at support@example.com.” Our messages should be written so everyone can understand, regardless of their technical knowledge.<\/p>\n\n\n\nWhat if the target group has a narrow specialization and specific needs?<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n
Let’s throw away negative words<\/strong><\/strong><\/h2>\n\n\n\nContent 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 9 Avoid negative words like “error” or “critical”<\/figcaption><\/figure>\n\n\n\nJokes and slang can be confusing and unprofessional. Instead, use clear and professional messages.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nSupport users<\/strong><\/strong><\/h2>\n\n\n\nError 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.<\/p>\n\n\n\nFig. 11 The message in the Google Chrome browser contains several tips on how to fix the Internet connection error (source<\/a>)<\/figcaption><\/figure>\n\n\n\nIf the error message is unclear or the problem is not resolved, users should be able to contact technical support.<\/p>\n\n\n\nFig. 12 Microsoft Office message indicates additional online help (source<\/a>)<\/figcaption><\/figure>\n\n\n\nMessages should be visible<\/strong><\/strong><\/h2>\n\n\n\nError 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nFor 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.<\/p>\n\n\n\n
What if red is the primary or secondary color in the visual identity?<\/strong><\/strong><\/h3>\n\n\n\nIf 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.<\/p>\n\n\n\n
We can add complementary colors, such as yellow or orange, in this situation. Another solution is to use warning icons that indicate an error.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 14 Crane application uses red as the secondary color to highlight selected elements (source<\/a>)<\/figcaption><\/figure>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nDisplay time<\/strong><\/strong><\/h2>\n\n\n\nAn 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.<\/p>\n\n\n\n
Avoid displaying errors prematurely<\/strong><\/strong><\/h3>\n\n\n\nPresenting errors too early can cause additional frustration and confusion for users. To avoid this, it is worth including strategies such as:<\/p>\n\n\n\n
\n- real-time validation,<\/li>\n\n\n\n
- delayed message display,<\/li>\n\n\n\n
- clear hints.<\/li>\n<\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nBe consistent<\/strong><\/strong><\/h2>\n\n\n\nWe 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.<\/p>\n\n\n\nFig. 17 <\/em>Inconsistent terminology is confusing<\/figcaption><\/figure>\n\n\n\nLet’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.<\/p>\n\n\n\n
Test<\/strong>ing<\/h3>\n\n\n\nObserve 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.<\/p>\n\n\n\n
Not only errors<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\nFig. 18 Success state when sending the form (graphic based on Newsletter przeprojektowani.pl (author of Newsletter \u2013 Rafa\u0142 Wr\u00f3bel)<\/a>)<\/figcaption><\/figure>\n\n\n\nThe role of humor<\/strong><\/strong><\/h2>\n\n\n\nHumor 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
When to use humor in error messages?<\/strong><\/strong><\/h3>\n\n\n\nHumor 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 19 The Twitch error message creatively informs about the lack of content at a given link (source<\/a>)<\/figcaption><\/figure>\n\n\n\nIf 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.<\/p>\n\n\n\n
Checklist<\/strong><\/h2>\n\n\n\nWhen 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.<\/p>\n\n\n\n
Here is an example checklist:<\/p>\n\n\n\n
\n- Describe the problem in simple and understandable language. Use full sentences.<\/li>\n\n\n\n
- Explain what caused the problem.<\/li>\n\n\n\n
- Avoid overly general statements.<\/li>\n\n\n\n
- Explain the solution to the problem. If it requires several steps, provide a link to a help page with detailed instructions.<\/li>\n\n\n\n
- Offer support or contact technical support.<\/li>\n\n\n\n
- Avoid technical terminology and write in the user’s voice.<\/li>\n\n\n\n
- Use friendly and understandable messages.<\/li>\n\n\n\n
- Do not blame the user for the error. Avoid text written in capital letters and exclamation marks.<\/li>\n\n\n\n
- Check if the message is easy to spot.<\/li>\n\n\n\n
- Design content consistent with brand values \u200b\u200band tailored to the target group. Remember the appropriate style and form of communication.<\/li>\n\n\n\n
- Check if the messages in the product are consistent not only in terms of content but also visually.<\/li>\n<\/ol>\n\n\n\n
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.<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nSummary<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Bibliogra<\/strong>phy<\/h2>\n\n\n\n\n- Error-Message Guidelines (nngroup.com)<\/a><\/li>\n\n\n\n
- Hostile Patterns in Error Messages (nngroup.com)<\/a><\/li>\n\n\n\n
- The ultimate error message UX writing guide (plus examples) (theuxgal.com)<\/a><\/li>\n\n\n\n
- Prosty j\u0119zyk – Dost\u0119pno\u015b\u0107 cyfrowa – Portal Gov.pl (www.gov.pl)<\/a><\/li>\n\n\n\n
- Poznaj 10 zasad prostego j\u0119zyka w Centralnym O\u015brodku Informatyki (www.gov.pl)<\/a><\/li>\n\n\n\n
- Book \u201eUX writing. Moc j\u0119zyka w produktach cyfrowych<\/a>\u201d, Wojciech Aleksander<\/li>\n\n\n\n
- How to Write Error Messages: Faster, Stronger, Better \u2013 Technical Writing Tools (ihearttechnicalwriting.com)<\/a><\/li>\n\n\n\n
- Tips for UX Writing – UX Magazine<\/a><\/li>\n\n\n\n
- How to Design Inline Editing and Validation in Tables – UX Design World (uxdworld.com)<\/a><\/li>\n<\/ol>\n\n\n
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.<\/p>\n\n\n\n
What does a clear error message mean?<\/strong><\/strong><\/h2>\n\n\n\nThe 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.<\/p>\n\n\n\n
A well-designed error message should include<\/a>:<\/p>\n\n\n\n\n- defining the problem,<\/li>\n\n\n\n
- why the problem occurred,<\/li>\n\n\n\n
- how the problem affects the user and their further actions,<\/li>\n\n\n\n
- how to solve the problem and what can be done to prevent it from happening.<\/li>\n<\/ul>\n\n\n\n
Key principles for designing error messages<\/strong><\/strong><\/h2>\n\n\n\nIn the following section, you will find information on properly designing error messages.<\/p>\n\n\n\nFig. 4 Instead of blaming the user, choose a neutral message<\/figcaption><\/figure>\n\n\n\nDon’t blame the user<\/strong><\/strong><\/h3>\n\n\n\nBlaming 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 5 Do not attack users with Caps Lock<\/figcaption><\/figure>\n\n\n\nBe specific and to the point<\/strong><\/strong><\/h3>\n\n\n\nError 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.<\/p>\n\n\n\nFig. 6. Provide clear information about the cause of the error and provide support<\/figcaption><\/figure>\n\n\n\nThe 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.<\/p>\n\n\n\nFig. 7 Avoid too generic error messages. Try to provide the error cause and solution<\/figcaption><\/figure>\n\n\n\nUse plain language and avoid technical jargon<\/strong><\/strong><\/h3>\n\n\n\nWrite 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.<\/p>\n\n\n\n
Remember, plain language partially contributes to digital accessibility. Read more about simple language on the government website<\/a>.<\/p>\n\n\n\nMessages should be written in plain and clear language. Whenever possible, avoid overly general statements and mysterious numbers, such as error 1020.<\/p>\n\n\n\nFig. 8 If possible, avoid cryptic error codes (graphic based on uxmag<\/a>)<\/figcaption><\/figure>\n\n\n\nIf we must use an error code, we can include it in the message. But remember, explaining what this means to the user is important.<\/p>\n\n\n\n
404: but that’s clear!<\/strong><\/h3>\n\n\n\nAlso, 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.<\/p>\n\n\n\n
Instead of:<\/strong> “Error 404: Page not found.”<\/p>\n\n\n\nUse:<\/strong> “We couldn’t find the page you were looking for. Check if the URL is correct, or return to the homepage.”<\/p>\n\n\n\nInstead of:<\/strong> “Error 500: Internal server error.”<\/p>\n\n\n\nUse:<\/strong> “There is a problem with our server. Please try again in a few minutes. If the problem persists, contact us at support@example.com.” Our messages should be written so everyone can understand, regardless of their technical knowledge.<\/p>\n\n\n\nWhat if the target group has a narrow specialization and specific needs?<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n
Let’s throw away negative words<\/strong><\/strong><\/h2>\n\n\n\nContent 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 9 Avoid negative words like “error” or “critical”<\/figcaption><\/figure>\n\n\n\nJokes and slang can be confusing and unprofessional. Instead, use clear and professional messages.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nSupport users<\/strong><\/strong><\/h2>\n\n\n\nError 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.<\/p>\n\n\n\nFig. 11 The message in the Google Chrome browser contains several tips on how to fix the Internet connection error (source<\/a>)<\/figcaption><\/figure>\n\n\n\nIf the error message is unclear or the problem is not resolved, users should be able to contact technical support.<\/p>\n\n\n\nFig. 12 Microsoft Office message indicates additional online help (source<\/a>)<\/figcaption><\/figure>\n\n\n\nMessages should be visible<\/strong><\/strong><\/h2>\n\n\n\nError 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nFor 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.<\/p>\n\n\n\n
What if red is the primary or secondary color in the visual identity?<\/strong><\/strong><\/h3>\n\n\n\nIf 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.<\/p>\n\n\n\n
We can add complementary colors, such as yellow or orange, in this situation. Another solution is to use warning icons that indicate an error.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 14 Crane application uses red as the secondary color to highlight selected elements (source<\/a>)<\/figcaption><\/figure>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nDisplay time<\/strong><\/strong><\/h2>\n\n\n\nAn 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.<\/p>\n\n\n\n
Avoid displaying errors prematurely<\/strong><\/strong><\/h3>\n\n\n\nPresenting errors too early can cause additional frustration and confusion for users. To avoid this, it is worth including strategies such as:<\/p>\n\n\n\n
\n- real-time validation,<\/li>\n\n\n\n
- delayed message display,<\/li>\n\n\n\n
- clear hints.<\/li>\n<\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 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<\/a>)<\/figcaption><\/figure>\n\n\n\nBe consistent<\/strong><\/strong><\/h2>\n\n\n\nWe 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.<\/p>\n\n\n\nFig. 17 <\/em>Inconsistent terminology is confusing<\/figcaption><\/figure>\n\n\n\nLet’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.<\/p>\n\n\n\n
Test<\/strong>ing<\/h3>\n\n\n\nObserve 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.<\/p>\n\n\n\n
Not only errors<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\nFig. 18 Success state when sending the form (graphic based on Newsletter przeprojektowani.pl (author of Newsletter \u2013 Rafa\u0142 Wr\u00f3bel)<\/a>)<\/figcaption><\/figure>\n\n\n\nThe role of humor<\/strong><\/strong><\/h2>\n\n\n\nHumor 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
When to use humor in error messages?<\/strong><\/strong><\/h3>\n\n\n\nHumor 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nFig. 19 The Twitch error message creatively informs about the lack of content at a given link (source<\/a>)<\/figcaption><\/figure>\n\n\n\nIf 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.<\/p>\n\n\n\n
Checklist<\/strong><\/h2>\n\n\n\nWhen 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.<\/p>\n\n\n\n
Here is an example checklist:<\/p>\n\n\n\n
\n- Describe the problem in simple and understandable language. Use full sentences.<\/li>\n\n\n\n
- Explain what caused the problem.<\/li>\n\n\n\n
- Avoid overly general statements.<\/li>\n\n\n\n
- Explain the solution to the problem. If it requires several steps, provide a link to a help page with detailed instructions.<\/li>\n\n\n\n
- Offer support or contact technical support.<\/li>\n\n\n\n
- Avoid technical terminology and write in the user’s voice.<\/li>\n\n\n\n
- Use friendly and understandable messages.<\/li>\n\n\n\n
- Do not blame the user for the error. Avoid text written in capital letters and exclamation marks.<\/li>\n\n\n\n
- Check if the message is easy to spot.<\/li>\n\n\n\n
- Design content consistent with brand values \u200b\u200band tailored to the target group. Remember the appropriate style and form of communication.<\/li>\n\n\n\n
- Check if the messages in the product are consistent not only in terms of content but also visually.<\/li>\n<\/ol>\n\n\n\n
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.<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nSummary<\/strong><\/strong><\/h2>\n\n\n\nIn 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Bibliogra<\/strong>phy<\/h2>\n\n\n\n\n- Error-Message Guidelines (nngroup.com)<\/a><\/li>\n\n\n\n
- Hostile Patterns in Error Messages (nngroup.com)<\/a><\/li>\n\n\n\n
- The ultimate error message UX writing guide (plus examples) (theuxgal.com)<\/a><\/li>\n\n\n\n
- Prosty j\u0119zyk – Dost\u0119pno\u015b\u0107 cyfrowa – Portal Gov.pl (www.gov.pl)<\/a><\/li>\n\n\n\n
- Poznaj 10 zasad prostego j\u0119zyka w Centralnym O\u015brodku Informatyki (www.gov.pl)<\/a><\/li>\n\n\n\n
- Book \u201eUX writing. Moc j\u0119zyka w produktach cyfrowych<\/a>\u201d, Wojciech Aleksander<\/li>\n\n\n\n
- How to Write Error Messages: Faster, Stronger, Better \u2013 Technical Writing Tools (ihearttechnicalwriting.com)<\/a><\/li>\n\n\n\n
- Tips for UX Writing – UX Magazine<\/a><\/li>\n\n\n\n
- How to Design Inline Editing and Validation in Tables – UX Design World (uxdworld.com)<\/a><\/li>\n<\/ol>\n\n\n
- \n
- defining the problem,<\/li>\n\n\n\n
- why the problem occurred,<\/li>\n\n\n\n
- how the problem affects the user and their further actions,<\/li>\n\n\n\n
- how to solve the problem and what can be done to prevent it from happening.<\/li>\n<\/ul>\n\n\n\n
Key principles for designing error messages<\/strong><\/strong><\/h2>\n\n\n\n
In the following section, you will find information on properly designing error messages.<\/p>\n\n\n\n
Fig. 4 Instead of blaming the user, choose a neutral message<\/figcaption><\/figure>\n\n\n\n Don’t blame the user<\/strong><\/strong><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Fig. 5 Do not attack users with Caps Lock<\/figcaption><\/figure>\n\n\n\n Be specific and to the point<\/strong><\/strong><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Fig. 6. Provide clear information about the cause of the error and provide support<\/figcaption><\/figure>\n\n\n\n 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.<\/p>\n\n\n\n
Fig. 7 Avoid too generic error messages. Try to provide the error cause and solution<\/figcaption><\/figure>\n\n\n\n Use plain language and avoid technical jargon<\/strong><\/strong><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Remember, plain language partially contributes to digital accessibility. Read more about simple language on the government website<\/a>.<\/p>\n\n\n\n
Messages should be written in plain and clear language. Whenever possible, avoid overly general statements and mysterious numbers, such as error 1020.<\/p>\n\n\n\n
Fig. 8 If possible, avoid cryptic error codes (graphic based on uxmag<\/a>)<\/figcaption><\/figure>\n\n\n\n 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.<\/p>\n\n\n\n
404: but that’s clear!<\/strong><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Instead of:<\/strong> “Error 404: Page not found.”<\/p>\n\n\n\n
Use:<\/strong> “We couldn’t find the page you were looking for. Check if the URL is correct, or return to the homepage.”<\/p>\n\n\n\n
Instead of:<\/strong> “Error 500: Internal server error.”<\/p>\n\n\n\n
Use:<\/strong> “There is a problem with our server. Please try again in a few minutes. If the problem persists, contact us at support@example.com.” Our messages should be written so everyone can understand, regardless of their technical knowledge.<\/p>\n\n\n\n
What if the target group has a narrow specialization and specific needs?<\/strong><\/strong><\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Let’s throw away negative words<\/strong><\/strong><\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Fig. 9 Avoid negative words like “error” or “critical”<\/figcaption><\/figure>\n\n\n\n Jokes and slang can be confusing and unprofessional. Instead, use clear and professional messages.<\/p>\n\n\n\n
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<\/a>)<\/figcaption><\/figure>\n\n\n\n Support users<\/strong><\/strong><\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Fig. 11 The message in the Google Chrome browser contains several tips on how to fix the Internet connection error (source<\/a>)<\/figcaption><\/figure>\n\n\n\n If the error message is unclear or the problem is not resolved, users should be able to contact technical support.<\/p>\n\n\n\n
Fig. 12 Microsoft Office message indicates additional online help (source<\/a>)<\/figcaption><\/figure>\n\n\n\n Messages should be visible<\/strong><\/strong><\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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<\/a>)<\/figcaption><\/figure>\n\n\n\n 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.<\/p>\n\n\n\n
What if red is the primary or secondary color in the visual identity?<\/strong><\/strong><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
We can add complementary colors, such as yellow or orange, in this situation. Another solution is to use warning icons that indicate an error.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Fig. 14 Crane application uses red as the secondary color to highlight selected elements (source<\/a>)<\/figcaption><\/figure>\n\n\n\n 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<\/a>)<\/figcaption><\/figure>\n\n\n\n Display time<\/strong><\/strong><\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Avoid displaying errors prematurely<\/strong><\/strong><\/h3>\n\n\n\n
Presenting errors too early can cause additional frustration and confusion for users. To avoid this, it is worth including strategies such as:<\/p>\n\n\n\n
- \n
- real-time validation,<\/li>\n\n\n\n
- delayed message display,<\/li>\n\n\n\n
- clear hints.<\/li>\n<\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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<\/a>)<\/figcaption><\/figure>\n\n\n\n Be consistent<\/strong><\/strong><\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Fig. 17 <\/em>Inconsistent terminology is confusing<\/figcaption><\/figure>\n\n\n\n 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.<\/p>\n\n\n\n
Test<\/strong>ing<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Not only errors<\/strong><\/strong><\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Fig. 18 Success state when sending the form (graphic based on Newsletter przeprojektowani.pl (author of Newsletter \u2013 Rafa\u0142 Wr\u00f3bel)<\/a>)<\/figcaption><\/figure>\n\n\n\n The role of humor<\/strong><\/strong><\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
When to use humor in error messages?<\/strong><\/strong><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Fig. 19 The Twitch error message creatively informs about the lack of content at a given link (source<\/a>)<\/figcaption><\/figure>\n\n\n\n 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.<\/p>\n\n\n\n
Checklist<\/strong><\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Here is an example checklist:<\/p>\n\n\n\n
- \n
- Describe the problem in simple and understandable language. Use full sentences.<\/li>\n\n\n\n
- Explain what caused the problem.<\/li>\n\n\n\n
- Avoid overly general statements.<\/li>\n\n\n\n
- Explain the solution to the problem. If it requires several steps, provide a link to a help page with detailed instructions.<\/li>\n\n\n\n
- Offer support or contact technical support.<\/li>\n\n\n\n
- Avoid technical terminology and write in the user’s voice.<\/li>\n\n\n\n
- Use friendly and understandable messages.<\/li>\n\n\n\n
- Do not blame the user for the error. Avoid text written in capital letters and exclamation marks.<\/li>\n\n\n\n
- Check if the message is easy to spot.<\/li>\n\n\n\n
- Design content consistent with brand values \u200b\u200band tailored to the target group. Remember the appropriate style and form of communication.<\/li>\n\n\n\n
- Check if the messages in the product are consistent not only in terms of content but also visually.<\/li>\n<\/ol>\n\n\n\n
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.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nSummary<\/strong><\/strong><\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Bibliogra<\/strong>phy<\/h2>\n\n\n\n
- \n
- Error-Message Guidelines (nngroup.com)<\/a><\/li>\n\n\n\n
- Hostile Patterns in Error Messages (nngroup.com)<\/a><\/li>\n\n\n\n
- The ultimate error message UX writing guide (plus examples) (theuxgal.com)<\/a><\/li>\n\n\n\n
- Prosty j\u0119zyk – Dost\u0119pno\u015b\u0107 cyfrowa – Portal Gov.pl (www.gov.pl)<\/a><\/li>\n\n\n\n
- Poznaj 10 zasad prostego j\u0119zyka w Centralnym O\u015brodku Informatyki (www.gov.pl)<\/a><\/li>\n\n\n\n
- Book \u201eUX writing. Moc j\u0119zyka w produktach cyfrowych<\/a>\u201d, Wojciech Aleksander<\/li>\n\n\n\n
- How to Write Error Messages: Faster, Stronger, Better \u2013 Technical Writing Tools (ihearttechnicalwriting.com)<\/a><\/li>\n\n\n\n
- Tips for UX Writing – UX Magazine<\/a><\/li>\n\n\n\n
- How to Design Inline Editing and Validation in Tables – UX Design World (uxdworld.com)<\/a><\/li>\n<\/ol>\n\n\n
- Hostile Patterns in Error Messages (nngroup.com)<\/a><\/li>\n\n\n\n
- Error-Message Guidelines (nngroup.com)<\/a><\/li>\n\n\n\n