April 2004 Meeting -- Non-Fatal Errors

June 2004

April 2004 Meeting -- Non-Fatal Errors: Creating Usable, Effective Error Messages
Presented by Emily Wilska
Reviewed by Keith A. Albert

Although error messages are everywhere, they are seldom as helpful as they could be, reported Emily Wilska at the April 2004 meeting. Why not? Error messages often contain technical jargon or potentially offensive terms, flag a problem without fully describing it, fail to suggest how to avoid it in the future, and end up confusing instead of assisting the user.

A better error message would timely deploy at an appropriate place; clearly describe the problem, its magnitude and its remedy (if one exists) in everyday language; not blame the user and quickly return her to her task. Even a modest amount of planning and elementary usability testing can pinpoint likely areas of difficulty for your likely users. Addressing these issues early on can help prevent users from encountering errors and a produce more directed, effective user documentation.

However, despite all precautions, there will always be errors. Some users read little or no text, different users interact variously with programs or websites, there often is not sufficient space for explanatory text, and technical communicators cannot always advise on software functionality, page flows and layouts.

When choosing a format, a technical communicator should consider the following three factors: the technical limitations of the documented program or website; the amount of information the user needs; and the quantity and type of user input required.

Short chunks of information are best handled in pop-ups, while larger amounts of information can be referred to a full-page text or split into smaller segments by using a pop-up with a More Info. button. If the number of requirements from the user is few (as in stating password rules), bulleted lists work well. Similarly, when the user can't fix the problem or only basic user action is required, pop-ups work best. More substantial user interventions are better served by a full page.

Error messages should clearly state what is wrong and quickly return the user to her task. Carefully consider how much information your audience needs to know and use task-oriented language. Furthermore, avoid Yes and No buttons because their prevalence and overuse causes many readers to simply click through without reading them. Imparting brief technical data may be of use if a technician will use it to troubleshoot the program. Finally, whevever possible, clearly state the action each button of the error message performs.

The tone of your error messages is enormously important to both the user's feeling about her interaction with your product (and consequently your product's subsequent reputation). Accordingly, error messages should never reprimand the user, but instead gently direct her towards corrective action. Error messages can employ a simple imperative, a fault-free declaration or a combination of the two. In the password choosing example, a simple imperative message might be Type a password that is at least 5 characters long, a fault-free declarative, Your password must be at least 5 characters long, and a combination phrase, Your password must be at least 5 characters long. Please type a password in the box below.

In conclusion, the quality of the error messages written into your product has a huge impact on the reception of your program or website. Writing error messages that make sense helps reduce help and documentation. Additionally, bad error messages can run up huge costs in customer service and greatly reduce customer satisfaction. By emphasizing that good error messages are a sensible investment that will reap significant future rewards, technical communicators can encourage management and the development team to plan and budget for their inclusion.

Keith A. Albert is a technical communicator in the Bay Area.