Designing the User Experience at Autodesk

Anatomy of an Error Message

By Cecilia Farell

“I’ve just picked up a fault in the AE35 unit. It’s going to go 100% failure in 72 hours.”

Some of you might remember this line spoken by the humanlike computer, HAL 9000, in Stanley Kubrick’s movie 2001: A Space Odyssey. Despite the trademark soothing voice (listen), HAL’s message has a chilling effect. Why? Because HAL doesn’t really say anything about what’s actually wrong (what’s an AE35 unit and how is it faulting out?). Even if he did, he offers no way of preventing the failure and whatever might happen because of it.

HAL of course is not unique. He “sounds” exactly like most of the applications and websites we interact with today. In the real world though, as HAL himself would put it, bad error messages are entirely attributable to human error.

The “good” in good error messages

Now that we’ve seen what a bad error message looks like, let’s talk about what you can do to make your error messages good. In a very early post on Alertbox, Jakob Nielsen identified five characteristics:

Explicit

An error message should first indicate that something is wrong. Let users know an error has occurred with an explicit and noticeable message.

Precise

Users also need to know what happened and where and, in some cases, why. But perhaps the most important piece of information they need is what the consequences of the error are, if any, so they can prepare for them. With this information, users feel in control because they know what to do to navigate away from the error.  

Human-readable

Error messages are for humans so they should be understandable by humans. Use plain language and write as a person speaking to another person. Avoid cryptic abbreviations and obscure codes. If you must use error codes, make sure they are supplemental and meaningful to your support staff.

Polite

Write your messages so they don’t punish users or make them feel stupid when they make a mistake (and they will). An error is always an inconvenience regardless of who or what caused it. So always take ownership of the mea culpa and show your customers that you care. This alone goes a long way towards alleviating their frustration.

Constructive

There’s really no point if an error message doesn’t say how to solve the problem and move on. This is where precision comes in again. Think of your messages as a tool to educate users so they can recover and navigate away from an error, and even learn how to avoid it in future.

Errors + error messages = user delight

Nielsen says that the worst error messages are those that don't exist. But it’s really the best error messages that are the ones that don’t exist because good design makes them unnecessary. No design, however, can do away with all errors. So error messages are here to stay.

With this in mind, Des Traynor treats error messages not as a negative but as an opportunity. For him, “all content is marketing” and “everything you write should be crafted with the intention of selling, educating, or increasing customer loyalty.”

If you agree with Traynor that “content is always an opportunity to delight your user,” error messages suddenly appear in a new light: as potential enhancements to the user experience instead of detractions. A perfect example is the whimsical customization of website error messages done to increase brand recognition and loyalty because of the customer’s emotional response.

HootSuite

PLM 360

You’ve heard of defensive driving; now there’s “defensive design”

Errors do happen, making design a lot like driving. The best drivers are those that anticipate driver errors and road problems so they can strategically react and recover from them when they happen. Likewise, the best designers anticipate user and application errors by designing for when things go wrong.[i] In other words, they practice defensive design.

Here are some basic guidelines for practicing defensive design from an article by Ian Lurie in Smashing Magazine:

• Validate to check input errors before they frustrate the customer
• Expand the available options based on the user’s implied intent
• Protect users from errors with informative messages
• Assist the user before errors happen

To learn more about defensive design and writing good error messages, check out the links below. Happy trails!

References

Hyde, John. “Handling User Error With Care: Getting Users Back on Track” in UX Booth, October 13, 2009. www.uxbooth.com/articles/showing-error-messages-to-users/.

Jarrett, Caroline. “Avoid Being Embarrassed by Your Error Messages” in UXmatters, August 9, 2010. uxmatters.com/mt/archives/2010/08/avoid-being-embarrassed-by-your-error-messages.php.

Kubrick, Stanley. 2001: A Space Odyssey. Entry in The Internet Movie Database (IMDb). www.imdb.com/title/tt0062622/ (HAL sound clip courtesy of The Movie Sounds Page. www.moviesounds.com/2001.html).

Lurie, Ian. “Getting Started With Defensive Web Design” in Smashing Magazine, May 27, 2011. uxdesign.smashingmagazine.com/2011/05/27/getting-started-with-defensive-web-design/

Nielsen, Jakob. “Error Message Guidelines” in Alertbox, June 24, 2001. www.useit.com/alertbox/20010624.html.

Traynor, Des. “All Content is Marketing” in The Intercom Blog, July 23, 2012. blog.intercom.io/all-content-is-marketing/.

_____. Microcopy That Strengthens Your Design’s Experience. Virtual seminar offered by User Interface Engineering. www.uie.com/events/virtual_seminars/how_seminars_work/

Waisberg, Daniel. “Optimizing Error Pages: Creating Opportunities Out of Mistakes” in Smashing Magazine, May 18, 2011. www.smashingmagazine.com/2011/05/18/optimizing-error-pages-creating-opportunities-out-of-mistakes/ 

---

[i] The concept of defensive design was introduced by Jason Fried, one of the founders of 37signals, and Matthew Linderman in their book, Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points. 1^st ed. New Riders, 2004. The phrase “design for when things go wrong” comes from the sub-title of one of the book’s chapters. You can buy the book on amazon.com.

 

Method 22 of 100: Affinity Diagramming

100 User Experience (UX) Design and Evaluation Methods for Your Toolkit

by Chauncey Wilson

This is the 22nd in a series of 100 short articles about UX design and evaluation methods. Today, I will discuss affinity diagramming, a method for organizing qualitative data into related groups as an individual or group. This method can be used to make sense of data from lab studies, field studies, open-ended questions, brainstorming, diary studies and other methods that produce qualitative data. Affinity diagramming is often done by a group of people in a room with sticky notes, but you can also do this remotely with tools like Google® Spreadsheet (see below), card sorting software and Microsoft® Sticky Sorter.  

View the full article

Bad design practices – Generalizing

By Lynn Miller

In my previous blog post I covered some of the factors that contribute to overdesign. There is one factor I would like to talk about in more detail: Overgeneralizing the problem.

Let’s say you own an old building that has been converted into apartments. During the renovations all of doors were modified to be a standard door height or higher, except one. One door at the back couldn’t be changed and is lower than the rest. People keep hitting their heads on this door and you would like that to stop as the liability insurance is getting expensive.

You bring in two designers who walk around the building observing everything, and who witness people bonking their noggins on the offending door. They go off and design their solutions.

Designer 1 comes back with a paper sign that she plans to affix to the top of the door. Then she will observe to see if it works and tweak wording and placement as necessary.

 

 

Designer 2 notes that one really tall guy needed to duck at all the doors, not just the low door, and that shorter people didn’t have a problem with the low door. So his solution is to put a sign beside every door that says what the clearance is (5’ 6”, 7’ 0”, 7’ 4”) so that the user can decide if they need to duck or not. This solution, he argues, works for all cases and makes the door signage consistent. He is so confident that he doesn’t think that testing is necessary and suggests you get 372 of these signs made right away in a nice walnut with copper trim.  He has even mocked up an example of what the sign should look like:

 

 

Designer 2 has overdesigned by assuming that a specific issue extends to a wider range of cases – in other words, by making the problem bigger than what has been observed. He has given equal weight in the design to the edge cases (very short or very tall people) even though there was no observed problem for them. If he didn’t actually see people having a problem at the other doors and has simply assumed there is one because of overgeneralization, then he is designing a complex solution when one is not required.  Not only is his design much more costly to implement, but because it is complex and doesn’t address the root issue (a low non-standard door takes people off guard) then it is not likely to even work.

There are many other issues with his design. Can you spot them all?