Humor in Error Messages

Process & Techniques
#1

I have written a few error messages for my company that contain mild, self-deprecating humor. The errors address a rare, anticipated bug during which the application times out shortly after launch and closes itself. For a few different versions of the error, the message reads:
[Application] has encountered an error and hidden in embarrassment. Please call Tech Support at . . . .
[Application] has stepped on its own toes. Please call Tech Support at . . . .

Note: There is no way for the user to fix the error alone.
I have received mixed feedback about the error messages. I have tried to interview users about the message, and when I offer options, users usually smile and laugh at the above messages, then state that they would prefer a more serious, jargon-filled message. I am concerned that the users are not saying what they really feel, but I don’t want to read my own bias into the interview results.
Some humor in error messages has usually delighted me in the past, but I am wondering if the practice needs to be different for bugs than for user error. Are there any thoughts on this topic or how to test it well?

2 Likes
#2

I’d love to hear from a couple of the @Experienced group here.

(FWIW I think your error messages are good fun.)

2 Likes
#3

I’ve got to honest here- while I like your thinking and I understand where you’re coming from, humour in error messages is something I’ve found to be quite frustrating in practice as a user.

In some cases it has felt a bit patronising - I’m not saying that yours is- just that sometimes it feels like the issues are being trivialised and it’s frustrating because I have very little spare time and I’m trying to do something and I am getting screwed over by technology that thinks it’s funny! Grrrrrrrrr :tired_face: Not funny at all. That’s just my opinion though- you don’t have to listen to me. :slightly_smiling_face:

In regards to how to test it, you need to see if the error message is doing its job. From what you’ve said, that job is essentially to tell them there’s been an error and that the only way to fix is by contacting someone. If you haven’t already, you might consider asking people during the context of scenario based testing what that error means to them and to show you/explain what they’d expect to have to do next.

From a content perspective- regardless of whether or not you keep the humour- you might consider adding something extra at the end eg:

[Application] has stepped on its own toes. Please call Tech Support at . . . . to resolve the issue.

It might help to explain why they need to go to the effort of contacting someone so they can get back to completing their task :slight_smile:

2 Likes
#4

hi @nesbeth22

first of all, I like your sense of humour!
Second, this topic is extremely interesting!

Said that I don’t have any data/study to validate my view on this case.

I believe that the communication between the system (the interface in this case) and the user has to be consistent with the momentum.
I stumble on an error message, I want to know ASAP how to solve it and go ahead with the process.
If the content you provide, no matter with/without the sense of humour, helps me to solve the issue I will be more than satisfied with reading it.
On the other hand, if this content is well written but it forces me to think what is the next step to do, in order to get rid of the issue, then I will be more than upset in reading it.

I think the silver bullet here is to provide precise instructions.
If you’re able to do this with a “human” tone of voice, this will increase the empathy between the user and the system and you will design a fantastic product!

Do u agree on that?

4 Likes
#5

I also agree with @dopamino.

It is our job to be certain we’re providing as much competence as possible. If you find that the humor is helping to do that, then it could be a great concept. However if you discover the opposite, then it probably isn’t a good idea. Best of luck. And please let us know about your discovery.

1 Like
#6

I appreciate all the support! A few insights during my interviews have seemed valuable. First, I think the humor made the users feel something was being left out or they might not have anything of substance to tell tech support, so I am considering “Naming” the error at the bottom of the message after the CTA (Error name: permissions error, etc.). Second, one user mentioned that she liked the technical message because it would make her feel a sense of urgency, and she would then call, get her solution sooner, and have a better overall experience. I’m revising a bit based on this feedback and will retest and post what I discover.

2 Likes
#7

Yes, I think the practice should be different for bugs than user error.

A bug is still a bug - it shouldn’t be happening. For the time it would take to consider and author self-deprecating microcopy, would it not be better to fix the bug? (Maybe that’s moot if the issue is in someone else’s hands or an external dependency or something…)

Also, you mentioned you’re receiving mixed feedback about the error messages - is that purely through the interviews you initiated, or have you received unsolicited comments about it? I ask this question because the challenge with soliciting feedback from people is that they’ll often synthesize an answer for you even if the topic wasn’t even on their mind a moment ago. Then we’re getting into hypothetical or sometimes espoused reactions, to your point about bias. And of course people in those situations may also moderate what they say because they want to be nice.

Is this an internal or customer-facing product?

I ask this because I think it would also inform your approach to the tone of voice. You can probably get away with more experimenting if it’s an internal app.

I like what Nielsen Norman Group has done with setting up 4 dimensions of tone of voice, each dimension being a point somewhere between pair of opposed adjectives like playful vs. serious. Theoretically, you could test microcopy with users on these dimensions and see which approach gets you closer to the tone you want to strike.

If this is for a customer-facing app, I think the tone you take needs to match the customer expectations and context, and probably defer to brand personality as well.

One more thing - slight tangent here, but I would wager that a playful approach to error messages is more memorable than a jargon-filled approach. That’s an assumption you could easily rule out with a 5-second A/B memory test, playful vs. serious. But my point is that bugs shouldn’t be there at all, let alone be conspicuous and memorable…

#8

Thanks @StudyOfPeople, for your thoughtful response. I have since investigated the source of the original complaint. It stemmed from our Tech Support department. An interview with the person who took the call revealed that the customer had no issue with the tone of the message, but the representative disliked it personally. I do wish I could just solve the bug, but for whatever reason our development team considered it a far edge case. That said, the research was far from time wasted. My design team is currently assembling our Living Style Guide, which will include definitions of error message structure and voice, so your Nielsen Norman link was on point. We are partnering with our marketing team on carving out the voice in all messaging.
Your point about memorability of bugs is a solid one, and makes me inclined to steer away from the humorous approach in messages for known bugs.

5 Likes