Non-Fatal Errors: Creating Usable, Effective Error Messages Emily Wilska MSN TV User Experience STC San Francisco chapte

1. Non-Fatal Errors:Creating Usable, Effective Error MessagesEmily WilskaMSN TV User ExperienceSTC San Francisco chapter meetingApril 21, 2004

2. Why care about error messages? What doesn’t work? What is a good error message? Prevention can be the cure Making unavoidable error messages less painful Getting buy-in for error message creation Q and A Workshop overview

3. Error messages are often an afterthought in project planning and implementation When we do finally get around to dealing with them, it can be too late to take the time to make them useful and usable Well-written, helpful, timely error messages can help users finish tasks more easily, can help decrease customer support costs, and can give users a better overall impression of the product Usable, effective error messages can help make technical communicators’ jobs easier Why care about error messages?

4. Each time I connect to my ISP, I see this error message: Visual C++ Runtime Library Runtime Error! This application has requested Runtime to terminate it in an unusual way. Please contact the application’s support team for more information. OK What doesn’t work?

5. Huh??? $*&%^! How does Runtime usually go about terminating this application? What isRuntime, anyway? Why am I seeing this message? Is this information I can use? I need this message to go away. Now. What will clicking OK do? I should get a new ISP My reactions to this message

6. It uses technical language I don’t understand, as well as the potentially offensive word “terminate” It tells me about a problem without giving any hint as to what the result of the problem might be or why I should care It gives no indication of how I might avoid the problem in the future It provides only a vague suggestion on how I might learn more about the problem (who is the support team?) It stops me from doing what I want to do: surf the Web It leaves me confused, frustrated, and wondering what’s wrong with my ISP Why doesn’t it work?

7. A good error message is one that Appears at a logical point in the user’s task Is suitable to the scope and severity of the error Clearly tells the user what the problem is and, if possible, how to fix it Avoids needlessly technical language and potentially offensive terms Doesn’t blame the user for the error Helps the user solve the problem and get back to his or her task as quickly and painlessly as possible What is a good error message?

8. It’s far more effective to stop problems before they happen than it is to allow them to happen and expect users to recover Even a modest amount of advance planning and some basic usability testing can help you determine where your users (or your product) might run into trouble Anticipating and designing around potential errors can help prevent your users from encountering error conditions in the first place This practice can also help you write more directed, more effective user documentation Prevention can be the cure

9. Assume you’re working on a new section of a Web site that will require users to create a password How might you anticipate and help prevent user errors here? Indicate password requirements on the page List requirements close to the text input box for the password Avoid making password requirements needlessly difficult or involved Explain the requirements in clear, straightforward language Prevention in practice

10. Not all users will read all (or any) on-screen text Different users interact with programs in different ways There isn’t always sufficient space for explanatory text It isn’t always possible for technical communicators to provide feedback and recommendations on aspects of a project such as software functionality, page flows, and layouts Errors can, do, and will happen Prevention goes only so far

11. All error messages should provide some basic information: What is the problem? What, if anything, can the user do to fix it or recover from it? What, if anything, can the user do to prevent this problem in the future? Making unavoidable error messages less painful

12. Just as important as providing this information in the first place is providing it in a way that will be helpful to your users For each error message you create, take into account: Format Content Tone Presentation matters

13. The format you use for error messages depends on three main factors: The technical limitations of your program or Web site The amount of information you need to present in the error message How much and what type of user input is required to fix the problem Presentation: Format

14. Web, software, and hardware technologies vary widely, as do their limitations When planning error messages, take into account the capabilities and restrictions of the specific technology you’re working with Planning for error messages in a format your product doesn’t support can result in wasted time and hastily redone errors Technical limitations

15. The format of your error messages should also stem from how much you need to tell your users Short chunks of text can easily be lost on a page with other content; on an otherwise empty page, they can look out of place For these, consider pop-ups Messages that provide more information might not fit in a small pop-up or panel; some information could be cut off if you try to force fit it Full-page error messages are often a better choice Amount of information presented

16. Finally, your format should depend on how much and what type of input (if any) you require of a user to correct a problem Errors that inform users of problems they can’t fix, or that require only basic user action, are well-suited to pop-ups Errors that require the user to take more substantial action (e.g., retyping information, answering a question) are better suited to on-screen text or full-page errors User input required

17. The main goal of error messages is to tell users what’s wrong, and then get them back to their tasks as quickly as possible Carefully consider how much detail about the problem your users will need Know your audience In complex or severe error cases, a bit of technical info can be helpful IF a technical service rep will use it to help troubleshoot Presentation: Content

18. Also consider the importance of the language you use in error messages, both in the body text and on buttons Task-oriented language tends to work well, as it directs users toward clear action Where possible, avoid Yes/No questions If it’s not obvious from the context, clearly state the action associated with each button on the error message Presentation: Content (2)

19. Your users will make dumb mistakes, but emphasizing that dumbness in your error messages will only make matters worse Avoid the (sometimes overwhelming) temptation to blame the user Use the imperative, the fault-free declarative, or a combination of the two The tone of your error messages is enormously important both to the user and to your product’s reputation Presentation: Tone

20. Use icons on error messages judiciously; they can sometimes carry unexpected implications Common icons: Stop sign (unrecoverable error) Yield sign (recoverable if user takes action, or just a warning) Info icon (message provides instructions or information only) Presentation: Tone (2)

21. How can we improve this message?

22. How can you prove to others that it’s worth their time, effort, and resources to include error messages in a project plan? Ask others to consider the cost of ignoring error messages altogether, or of shipping a product with sub par error messages Emphasize the importance of good error messages in terms of reduced support costs, a user-friendly product, and more satisfied customers Build on the project team’s pride in the work they’ve done Getting buy-in for error message creation

23. An early version of my company’s Internet service included this error message: This page is too big to be shown completely. Done What’s the cost of ineffective error messages?

24. What did the message mean? Why were users seeing it? How could they get rid of it? Why was this ineffective?

25. These are the questions they called and emailed Customer Service to ask, to the tune of nearly $50,000 over a two-year period That works out to about $2800 a word We also paid in terms of customer satisfaction A relatively small amount of effort would have saved us a lot of money, and would have saved customers a lot of frustration The cost

26. Encourage managers to think of creating good error messages as an up-front investment of time and effort that will pay significant dividends when the product is released Lower support costs Decreased likelihood of having to make error message-related changes in a later release Happier customers (who might pass the word along) Emphasize the potential gains in customer satisfaction and product quality Getting buy-in from management

27. Acknowledge the team’s sense of ownership of and pride in the product, and present error messages as a positive contribution Emphasize that error messages can help reinforce the team’s efforts to create a quality product Encourage team members to think of effective error messages as an easy way to increase customer satisfaction Getting buy-in from your project team

28. “When a user sees your error message, the Web site or product has let them down.” (Scott Berkun) The challenge technical communicators face is to keep that disappointment as brief as possible, and “to shorten the distance between the user’s goal and the completion of that goal.” You have the ability to make your product’s error messages non-fatal Remember this

29. Q and A wilska@microsoft.com