Conversion Zen: Transforming Errors Into Opportunities

Who’s responsible for your site’s error messages? Who decides what they say, when they appear, and how they look? It’s a key question—because if you haven’t paid attention to how your site treats visitors when things go wrong, their experience is much more likely to be negative—and talked about.

This article is second in a series I began in July, with Turning Errors into Opportunities. In that article, I examined some ways to not only improve the effectiveness of error messages, but even go a step further and optimize them for conversion. Here, I’ll take a look at why so many sites have terrible error experiences, and who should be in charge of fixing it.

Why the error experience is important (continued)

As I mentioned in my first article, a poorly designed error experience is similar to poor customer service; the “rude saleslady effect” can compound the original problem, cementing the experience in a visitor’s mind. What does this mean? It means the visitor will remember the problem. Even worse, the visitor is very likely to tell his or her friends about it.

In recent study of more than 75,000 people, the Customer Contact Council examined the links between customer service and loyalty. From that study, titled “Stop Trying to Delight Your Customers,” comes a sobering set of statistics:

• 23% of customers who had a positive customer service interaction told 10+ people about it.
• 48% of customers who had a negative interaction told 10+ people about it.

Perhaps we already knew this instinctively, but what those numbers tell us is people are basically twice as likely to complain as they are to praise.

Given those kinds of stats, let me loosely quote the great Clint Eastwood and ask, “Do you feel lucky? Well, do ya?” Put another way: Is your brand so strong, your site so dominating in the marketplace, that you can risk poor PR? Because your site’s error experience could be generating negative attitudes and word of mouth about your site and company, without your even being aware of the reason or the source.

Why do so many sites have bad error experiences?

If the error experience has such a significant potential impact, why do so many sites execute on it so poorly? Aren’t the site owners paying attention? Surely they didn’t give the green light to that rude, dismissive tone, that nearly invisible design treatment, that complete absence of any helpful instructions… right?

I’d like to believe that these next examples never crossed anyone’s desk for review and approval:

Example 1: an error that displayed at a prime conversion moment—during a ticket purchase attempt.

Example 2: Unknown, unsung site. My response: “So 1990’s!”

Example 3: an error message shown on the payment page of an e-commerce site. The “error” was a typo in the credit card number, but how could anyone tell, reading this message? Assuming they noticed it in the first place, of course.

Example 4: An all-too-typical JavaScript popup error message, complete with odd grammar and suspicious spelling.

Example 5: Poor handling of an empty search results set. Where’s the conversion love?

As I said, I’d like to think these error messages never received any attention at all, beyond their initial coding. And for many sites, that’s exactly the problem. Typically, no one is specifically tasked with designing and optimizing error experiences.

Why is that?

Reason #1: We’re all too darn positive

Yes, that’s right, I’ll say it—every member of the web site team is too optimistic. We have to be, in order to believe we can build and grow a successful online business these days. And as a result of this “can-do” attitude, we don’t want to think our uniquely beautiful, powerful and soon-to-be-profitable web site will have problems. The error experience isn’t part of our critical path—we’re focused on making all the big exciting stuff—our cool proprietary app, landing pages and the checkout process—work.

I hate to be a downer here, but it’s time we look at the gloomy side of life for a moment. Errors are inevitable, and the sooner we accept this depressing fact the sooner we can begin to change the effect errors have.

Reason #2: Error messages are invisible

Error messages are part of a site’s hidden, internal workings. For sites developed on a CMS platform, error messaging is often scattered across a tangled nest of code modules—difficult to find, much less aggregate and review. And for most small- and mid-sized site development projects, errors typically aren’t called out in the specs brief, presented during the design or copywriting process, or included in a review checklist.

So who sees error messages?

Customers, of course. But let’s assume that they shouldn’t be the first or only ones to do so.

Who else sees error messages? Developers are often the first to see them. Possibly visual designers will seem them, if the development team calls for an “error color” to use. And the quality assurance team (assuming there is one) will see them.

But should any one of these three teams be responsible for the error experience design? I’d argue no, and here’s why: left to their own devices, developers will write cryptic messages that make heavy use of words like “grok” and “runtime”, while designers (and I’m as guilty of this as any) will spend a disproportionate amount of time making the text look pretty. The QA team, for its part, is there to review against a defined checklist, not to perform an open-ended user experience review.

All three teams should be part of the process, but they need clear criteria around the error experience, so they know how to code, design and judge it properly.

But back to an earlier question—who’s responsible for this set of criteria? And what should those criteria contain?

The who

Here’s a list of the people I think should be involved in error experience design, and what their responsibilities and criteria should be. Not too surprisingly, the responsibilities are divvied up between the usual web teams—there’s no need for a dedicated error czarina here, I’m simply adding error experience design as an explicit task for each team.

Project or Program Manager: Responsible for putting error experience on the calendar and on the checklist. Ensures that errors are:

• Defined and catalogued
• Prioritized by importance to business goals and ROI
• Included in the development and QA timelines

Usability Practitioner: Responsible for error definition, UX education and review.

• Uncovers non-obvious user interactions that should be defined and treated as errors
• Provides best practices for error experience design
• Provides UX input for iterative drafts of copy, visual design and interactivity

Copywriters: Responsible for what errors say. Ensures that the error copy:

• Apologizes
• References the exact error that just occurred
• Maintains a clear, branded, audience-appropriate tone
• Provides helpful, actionable, conversion-optimized next steps specific to the error

Visual Designers: Responsible for how errors look. Ensures that the error design:

• Attracts attention
• Indicates the location of the error
• Visually reinforces the company brand and tone
• Visually emphasizes the available next steps

Developers: Responsible for how errors act. Ensures that the error functionality:

• Triggers errors at the most appropriate moment (per defined business rules)
• Enables interactivity that enhances and supports the desired visual display and next steps
• Logs debugging and other technical information

The Result: Awesome, conversion-optimized error messages

When the combined genius of a web team is turned to optimizing the error experience, wonderful things happen.

Here’s an interesting example from a current conversion optimization project of ours. This simple display involved input from UX, development, copywriting and design before we deemed it good to go:

Part 1: Attract attention to the error. The message appears in a JavaScript overlay, using a contrasting color combination. Notice we’ve made the text a template, so it can be easily re-used for other errors related to the form.

Part 2A: The form field without an error indicator.

Part 2B: Indicate the error, keeping it as clean and simple as possible.

A few final examples

I’ll leave you with a few more inspirational examples that provide pointers in the right direction:

Example 1: The copy identifies the error, communicates the site’s unique tone with humor, and guides the visitor to several next steps.

Example 2: Simple and visually clear indication of where the visitor needs to correct errors.

Example 3: The display attracts attention; the text apologizes and describes a clear path to solve the issue.

Example 4: Attracts attention, explains what happened, and describes a clear next step. More subtly, the site effectively addresses an error that many sites don’t deal with very well—a session timeout.

OK, that’s it for this time! If you come across great—or horrible—error examples, be sure to call them out in the comments below.