How to write a good error message: the rules to follow

The error messages in software are an essential part of the history of computing. Since the dawn of computing, when computers were huge punch card machines, it has been necessary to develop ways to communicate to users when errors or problems occurred in calculations. Here's a historical overview:

• The origin: early computers did not have displays or screens as we know them today. Instead, errors were noticed through printers and beeps. For example, the famous 'beep' of IBM mainframe machines notified errors in data processing.



• Text screens: with the arrival of personal computers in the 1970s and 1980s, text screens were introduced that could display error messages directly to users. These messages were often simple and cryptic, but they notified the error.




• Graphical user interface (GUI): with the spread of graphical user interfaces in the 1980s and 1990s, error messages became more visually rich and understandable. Pop-up dialogue boxes with icons and more descriptive texts became commonplace.



• Modern programming languages: with the development of modern programming languages and development tools, programmers have been able to customize error messages and provide more detailed information. This has helped simplify troubleshooting for developers.



• Internet and web applications: with the spread of the Internet and web applications error messages have become even more important. Developers of websites and web applications had to find ways to clearly communicate connection, access or missing data errors to users.



• Focus on usability: in recent years there has been an increased focus on the usability of error messages. Best practices now include clarity, kindness, providing solutions when possible, and intuitive support to help users solve problems.

Briefly, error messages in software have evolved considerably since their initial conception, moving from audible or printed indicators to visually rich and informative error messages. Their importance continues to grow as software and applications become more complex, emphasising the need for effective communication with users when problems occur.

Here are the rules to follow in order to write a good error message.

1. Be clear and brief: the error message should be direct and easily understandable. Avoid ambiguous language or complex sentences.



2. Use a friendly language: try to avoid an accusatory or punitive tone. Use polite and respectful language to help the user feel comfortable.



3. Identify the problem: explain clearly which error was detected. For example, "Connection error" or "File not found."



4. Give a brief description: add a short description of why the error occurred. For example, "Unable to connect to the server. Check your internet connection."



5. Suggest a solution: if possible, suggest at least one solution or a series of steps to resolve the error. For example, "Restart the application" or "Check your username and password."



6. Use error codes: if it's the case, include a unique error code that developers can use to identify the problem more specifically.



7. Show error location: if the software is complex or has many functions, tell the user where the error occurred or what action caused it.



8. Offer a support contact: if the problem cannot be solved by the user, provide a contact for technical support or a link to further resources.



9. Avoid technical words and acronyms: if possible, avoid technical terms or acronyms that the user might not understand. Use a simple and accessible language.



10. Provide an 'OK' or a 'Close' button: include a button or option to close the error message. Ensure that the user can continue without having to restart the application.




11. Test the error message: before releasing the software, test the error message to ensure that it is accurate and provides useful information.

Here is an example of what a well-written error message might look like:

Connection error. Unable to connect to server. Please check your internet connection and try again. [Check connection] [Contact support].    

In general, all error messages should provide guidance to solve the problem.

It would be best to prevent the operator from arriving at the error message.

For example: if I input a customer with an incorrect VAT number, it would be better to warn him before giving OK for the entry.