How can you write error messages that don't frustrate users?

Writing error messages that are helpful rather than frustrating is important for a positive user experience. It should Clearly explain what went wrong in simple and non-technical language. Use language that feels human and avoid sounding overly formal or robotic. Here are examples of a frustrating error message and a user-friendly alternative. Frustrating: Error 404: Not Found user-friendly: Oops! It looks like the page you're trying to reach doesn't exist. Please check the URL or try navigating back to the homepage. Frustrating: Error 500: Internal Server Error User-friendly: Oops! Something went wrong on our server. Don't worry, our team has been alerted and is working to fix it. We apologize for any inconvenience.

The purpose of error messages is to indicate the user that there has been an error and here’s a way to solve it. It shouldn’t in anyway confuse users about the next step. Here’s how I approach it in the first go 1. Break the error statement into parts. Don’t use complex sentences. 2. Give users the context or the “Why” of the error 3. A simple structure can be “error + context + how can it be resolved “ 4. If the resolving part of error involves lot of steps and there exists a page of all the troubleshooting steps, provide the user with navigation anchor 5. Finally keep the message short so that user doesn’t have to spend long time reading it

Prioritize clarity and simplicity. Clearly explain the issue using user-friendly language, avoiding technical jargon. Apologize for any inconvenience and provide specific guidance on resolving the problem. Use a friendly and empathetic tone throughout the message. Emphasize important details using formatting techniques and offer links to support resources. Ensure users can easily reach out for assistance if needed. Test the messages with real users to validate their effectiveness and make adjustments based on feedback. Ultimately, user-friendly error messages can transform moments of frustration into positive interactions, enhancing the overall user experience.

Craft error messages that are clear and concise, avoiding blame and using a friendly tone. Provide actionable solutions, highlight key information, and offer contact options for assistance. If appropriate, consider a touch of humor carefully. Test messages with users to ensure effectiveness.

Use Clear and Friendly Language: Write error messages in a simple and concise manner, using language that users can easily understand. Avoid technical jargon or complex terminology. Be empathetic and show understanding towards the user's situation, Provide Specific Information: Clearly state what went wrong and why, without overwhelming the user with unnecessary technical details. Offer actionable suggestions or steps to resolve the issue, if applicable. This helps users feel supported and empowered to address the error. Be Positive and Encouraging: Instead of blaming or scolding the user, maintain a positive and friendly tones

Ditch the tech talk: Talk like a real person, not a robot. Users need simple words, not confusing codes or acronyms. Problem solved, not problem focused: Tell them what went wrong, but skip the technical details. Offer clear steps to fix it, not just a technical explanation. Be their friend, not their foe: Use a kind and helpful tone. Show empathy, not blame. Let them know you're there to help, not scold. So, the next time you write an error message, think of it as a helping hand, not a roadblock. Use plain language, offer solutions, and be kind. You'll be surprised how a few simple words can turn frustration into understanding, and even a smile. Remember, clear communication is the bridge between a good experience and a great one.

Acredito que, além de entender o contexto do erro, é muito importante entender para quem você está escrevendo. Podemos fazer um comparativo entre dois bancos: Nubank e Safra. O Nubank tem um amplo público jovem e iniciantes no mundo financeiro, sendo o banco mais utilizado por este grupo, enquanto o banco Safra possui uma gama enorme de investidores, empresários e clientes de alta renda. O que difere um do outro na hora de comunicar um erro é justamente PARA QUEM está sendo comunicado. Uma linguagem formal com termos específicos da área financeira podem n?o ser t?o claros e assertivos para um público, mas para outro pode ser exatamente o que o usuário precisa. Conhecer o seu usuário é fundamental na hora de se comunicar com ele.

Ah, the classic "Error 404: Page Not Found." It's as clear as mud! Some e-commerce sites seem to think being cryptic is more fun. Instead of "Oops, this page doesn’t exist," they might as well say, "Good luck figuring out what went wrong!" But the best are those that keep it simple and clear – "This page is lost in space," with a cute little astronaut, perhaps? Additionally, personalization is the key here... The best sites make you feel like they know you. "Hey Dave, this page isn’t here, but here’s something you might like!" Some sites try to be cool and end up sounding like a dad at a disco. "Whoa dude, you broke the internet!" or "Our server is having a bad day." It's like they're trying too hard to be the 'fun' brand.

Crafting error messages with politeness and empathy is crucial for a positive user experience. Some of the points that I use and can recommend are: 1. Be concise and specific about the issue. 2. If the error is on the system's end, acknowledge it with a simple apology. 3. Suggest actionable steps to resolve the issue. 4. Frame the message in a way that doesn't blame the user. 5. Include a link to support resources. 6. Keep the language positive and encourage users to try again. 7. In certain contexts, light-hearted or witty language can diffuse frustration. With following this easy points you will guide users through the issue with understanding and support, turning a potential frustration into a positive interaction.

Some sites get it: "Oops, our bad." Others sound like they're blaming you: "You entered the wrong URL." Like, sorry for intruding on your perfect website, Mr. Internet!

- Use simple language: Avoid using technical jargon or acronyms. Speak in a way that everyone can easily understand. - Be specific: Don't just state that "Something went wrong." Instead, explain what exactly went wrong and why it happened. - Use humor with caution: While lighthearted humor can be effective in unexpected situations, try to avoid forced jokes or sarcasm.

Imagine you've been asked to make a cup of coffee, but every time you serve it, the customer says it's not right. Now imagine that you've been asked to make another cup of coffee, and the customer tells you how they want their coffee. Moreover, they tell you what went wrong as soon as you made a mistake. Similarly, it's important to communicate to your user what you expect from them in an input field for example. If they enter incorrect information, don't just tell them it's incorrect, instead tell them how they can correct it. E.g. instead of saying "try a different password", say "special characters not accepted in passwords". Also be more reactive with the error messages, rather than waiting for them to find out during submission.

I totally agree that you should consistently add solutions and or guidance to error message, however on occasions this may not be necessary. Sometimes we may need to consider effort Vs impact both from a dev and UX/UI side in creating a new or bespoke errors for a specific issues which may not be very common or frequent within a program. In this case is it worth it? On other occasions it me be better to educate a user or consider something else when it comes to glitches, complex technical issues or compliance.

An error message appears when the product can’t complete the function that the user is looking for - so let’s guide them to completing that function. An error message that is a dead end forces the user to backtrack with almost no new information, especially if the user is unaware of how they got there, if we utilize error messages/screens as a pseudo-landing-page we can direct the user to where they might’ve been trying to go and the user flow continues!

Depending on the type of error that occurs, you can offer users various options: retry, reset, contact an administrator, call support, download a log file, check online help, or simply return to the Home page. An error message adapted to the context will not eliminate frustration but can dramatically reduce its intensity.

Iterating on error messages through testing is crucial, yet there are instances where we lack the opportunity to test and refine them as extensively as desired. Typically, I start by generating several options based the guidelines above and then conduct some informal gorilla user testing with any one around me. I adjust and modify the wording as necessary during this process.

The clever sites: - use their error pages as a secret weapon. - track them, analyze them, and constantly evolve. - are always tweaking their error pages based on user feedback. The not-so-smart ones? They probably don’t even know they have error pages

Visual Design??: Ever seen a 404 page that's a visual feast? Some sites get it right with on-brand colors and a design that makes you almost glad you landed there. Then others look like they let their intern design the page during lunch break. A little creativity goes a long way, folks! SEO Considerations: Ever dived into the backend of these error pages? It's like exploring a jungle. Some are well-optimized, while others are SEO blackholes ?? Guidance and Navigation ??: The best sites turn a mistake into an opportunity. "Lost? Let us help you find your way back." Others just leave you stranded. "Error 404. That's it. Good luck out there." It's like being dropped in the middle of a maze with no exit in sight.

As you expand your range of errors, it's advisable to maintain a table that catalogs all errors across your product. Organise the errors within the table hierarchy, employing designated colors like red for alerts and orange for warnings. This approach allows you to efficiently track your errors, enabling you to assign colors, grades, and maintain consistent language when dealing with newly created errors.