Are we sorry?
In my position as content strategist, I am sometimes tasked with writing error messages. They seem innocuous enough. Tell the user, “We’re sorry, there’s been an error,” and move on, right?
Not so fast.
It seems natural to start the error message with “Sorry.” In conversational speech, we use it all the time. “I’m sorry?” when we didn’t catch what the other person said. “I’m sorry…” when we need to reach around someone at the grocery store. “I’m sorry,” to convey sympathy for another’s misfortune. And, of course, “I’m sorry,” to apologize for a misguided deed.
Though we have morphed “I’m sorry” from an admittance of guilt and expression of remorse to more of a synonym for “excuse me,” “I’m sorry” still holds a primary space in our language as an apology. How many times have you responded, “Wow, I’m sorry,” to a tale of woe, only to be met with, “It’s okay, it’s not your fault”? Regardless of the intent, “I’m sorry” seems to be best recognized as an apology and acknowledgment of responsibility.
With this in mind, let’s return to our error message assignment. When should we apologize? We believe it comes down to this:
We apologize when a situation on our end – intentional or unintentional – prevents the user from moving forward or completing an action.
Server down? We’re sorry. A bug? We’re sorry. Landshark? We’re sorry. In these cases, the user had absolutely nothing to do with any of these situations, and we will apologize for the inconvenience.
So then, in what situations would we withhold an apology? If a user needs to register before completing an action, we don’t apologize. If a user misses a required element on a form and cannot move forward, we don’t apologize. If a user intentionally or unintentionally violates our policies, we don’t apologize. In these cases, it is the user’s action that causes the error, and we don’t apologize; we inform and politely guide the user to the correct action. It doesn’t mean we don’t care about the user’s plight, but we don’t claim responsibility for it.
It sounds simple, but it gets tricky. “Was the IA too difficult, and therefore, our fault?” “Did we not message this policy correctly, and therefore, our fault?” “Should we have warned them the candygram was actually a landshark, and therefore, our fault?” You could drive yourself crazy doing this, so keep it simple. If the IA is bad, revisit and fix it later, but don’t apologize for it now.
And because this clip played repeatedly in my head as I wrote this, I now give you a moment of cinematic triumph:
4 Comments
Keri on February 10th, 2009
Regarding the clip: Sigh.
Regarding design and fault: Totally agree with you and Norman. Good design means preventing errors from happening. But is your stance, then, that all error messages should include an apology? Do we assume all errors are ultimately our fault?
Or since you say we don’t want to apologize for user stupidity, do we determine which errors are design flaws and which ones are stupidity and construct error messages appropriately? How would that be done?
I much prefer the content work with the intent of the design and flow. It is the designers’ intent that the flow works (we hope!), and therefore, an appropriate error message would not include an apology. If it is found the flow does not work, the flow should be fixed – and not by adding an apology on an error message (oooh… content expected to shore up bad IA is a big, fat pet peeve of mine… I feel another post coming).
Angie K on February 10th, 2009
I agree. We shouldn’t feel compelled to apologize for user error in our error messages.
Which is better?
“We’re sorry. You need to fill in a valid user name to continue. .”
or:
“Oops! Please enter a valid user name. Pick one 5-10 characters long.”
The apology in the first example doesn’t really make sense. It’s basically saying “We’re sorry you’re stupid.”
The second example is just a quick reminder to the user to follow the instructions. It tells them what they did wrong, but with a smile. The user can immediately fix their error and move on.
That said, I don’t think an apology would hurt the situation. The most important thing to remember when writing error messages is to include instructions for how the user can right their wrong, with or without an apology. “Sorry” by itself won’t fix it.
NotSorry on February 11th, 2009
It’s a myth that “users don’t read web content,” but, they do read differently. They scan. Do we waste precious space with needless “We’re sorry.”
No.
We shouldn’t be sorry. We shouldn’t make excuses. We should use a sympathetic tone to quickly get the user back on track – to provide them with the information they need to move on.
I was part of a large voice and tone study where we actually tested “We’re sorry” – I hate to admit it, but most users appreciated those two little words. I stand by the fact we were in a lab and it was way out of context.
In certain circumstances, it works. Overall, should it be considered part of content strategy for error messages, trust & safety content, and restricted access to areas of the site (e.g.,
“we’re sorry, you need to upgrade blah blah blah”)? No. It shouldn’t.
Sorry. 
Rian on February 9th, 2009
I made it 31 seconds into the clip (I’m sorry, I just can’t do old movies…).
I have to throw out a counterargument though. In “The Design of Everyday Things” (http://tinyurl.com/cktojc), Don Norman argues that any design that leads the user to make a mistake is the designer’s fault.
Think of most digital camera batteries these days, for example. There are four possible angles to insert a battery into a camera, but it’s usually designed so that it doesn’t fit unless you put it in the right way. It’s designed to prevent errors from happening. Now, granted, we probably don’t want to apologize for user stupidity, but I guess our goal should be to design to prevent error, and maybe even own up to it if a user behave stupidly…?