Regretfully, error messages are a part of our craft, and if I ask around, there are few developers who would know how to write a good error message. To give you a good idea on how poor developers are at this, have a look at the error’d section of thedailywtf.  Although part of the UX, it is not the UX designer’s responsibility to write an appropriate error message. We can’t hire a copywriter for just writing these messages, so realistically for smaller teams this means that this is often done by the developer that wrote the code.

Is there a way to write a good error message?

Error messages are not necessarily caused by bugs in the code, and they are all about informing the user. The developer cannot help it when the internet connection does not work, or when a firewall is blocking the port that the application intends to use. The developer cannot help that hardware is failing and cannot connect to your smartphone. The developer cannot help that a power outage broke some sectors on your hard drive.

Simply said, the developer cannot control the possible reasons why something would not work. However, the developer can help the user out by writing a good error message. When you think of writing an error message answer the following questions: What happened and why?  What is the effect of this to the user? What can the user do to avoid this from happening again? For instance:

Unable to print the document because the application is unable to connect to the printer. Ensure that the printer is connected on both ends and that the printer switched on, and try to print again. If the problem persists please contact support.

When writing an error message, do consider the following guidelines:

1. Avoiding error messages. Good design, micro-interactions and common sense could prevent the user from seeing the error message altogether. In the given example, we can avoid the user clicking on the print button by disabling it and show that no printer is found. A tooltip can reveal the same instructions as the error message.
2. Avoid technical jargon. The only thing the developer is interested in is stack traces and exception types, and should end up on your to-do list through proper instrumentation.
3. Delivery of the message. Only respond with error messages to direct user interactions. Consider getting an alert window popping up in your face while an error is caused in some background process that you as a user are not even aware of!
4. Writing Style. Use simple and complete sentences. Avoid negative words, the word please, exclamation points, uppercase text, abbreviations and acronyms.
5. Humor. A recent movement includes humor. Great for a 404, but if the user is unable to save his hard work your big embarrassed smiley face may not get the response you were aiming for.

Overall, when you are able to give an error message that is straight to the point and easy to understand, it lessens the negative impact of the error that occurred. People will be more understanding of what happened and open to solutions provided.