Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

We are having a discussion on our team about an error message that says "Sorry, you do not have permission to access this feature. Please contact your administrator for assistance."

Is it appropriate to use language of "apology" in this instance? The rationale against it is that it would be more appropriate to "apologize" for something that would be considered solely the "fault" of the application such as downtime. ("Sorry but our site is currently unavailable...please try again later.")

share|improve this question
11  
I'd agree with that rationale. If user enters invalid input, its a mistake on user's part. And if software fails to do something user rightfully expects, its a mistake on software's part. –  user117 Jan 4 '13 at 16:13
50  
Keep in mind that "I'm sorry" does not necessarily mean admitting it's your (or anyone's) fault or mistake. It's often used as a more generic expression of sympathy or regret for what happened, aside from any discussion of whose responsibility it was. As in, "I was sorry to hear that your mother died." –  LarsH Jan 5 '13 at 19:13
23  
@barrycarter xkcd.com/945 –  Lewis Goddard Jan 6 '13 at 0:11
34  
You're always allowed to write "I'm sorry" in your error messages if it's immediately followed by "Dave" –  Matty K Jan 7 '13 at 1:42
12  
Not if it is used by lawyers - they will take it as an admission of liability ;-) –  Andy Dent Jan 7 '13 at 6:59

15 Answers 15

up vote 329 down vote accepted

The reason I believe it is important to have an apologetic tone is to ensure you are communicating to the user that, though a mistake has been made and he is interacting with a machine or application in this case, you still respect his action and are humanizing the mistake.

To quote this article from UXMatters:

“You’re going to display your error message to a person, so write it in the tone of voice you would use if you were telling the error message to the person directly.”

I also recommend looking at this excellent article, Are You Saying “No” When You Could Be Saying “Yes” in Your Web Forms?:

Error messages seem like an unimportant and incredibly boring part of crafting a user experience. But the tonality of error messages can swing the experience around from an almost certain abandonment to a conversion.

The article emphasizes that error messages should carry a positive tone and hence an apologetic response can help users quickly recover and not immediately become defensive about a mistake they might have made.

Writing error messages that carry a positive tone isn’t rocket science. Just follow a few simple rules:

  1. First, get rid of tech lingo such as “incompatible.” Most users won’t know what this means. Speak to them in their own language and not the language of your developers. For example, “incompatible” translates to “does not work together” in plain English.

  2. Don’t use negative words

  3. Clearly identify the error so the user knows what to correct.

  4. Give the user a hint of how the problem can be solved.

  5. Put the blame on yourself, not on the user.

I also recommend looking at The Effect of Apologetic Error Messages and Mood States on Computer Users’ Self-appraisal of Performance for a study which analyzed the impact of using apologetic error messages on user mood states and how human-like apologetic tones are effective in computer interfaces. To quote an extract from the article

In HHI, apologies are generally used to express regret (Leech, 1983; Schlenker andDarby, 1981) or to alleviate individuals’ anger caused from their disapproval of others’ action.In other words, apologies mitigate frustration and anger when attempted interactions fail.Similarly, Nielsen (1998) argues that error messages responding to the computer user’s action should include a simple apologetic statement when the reason for the error is the limitation of the computer interface to perform the intended task. Tzeng (2006) conducted a study investigating users’ perceptions of online systems containing three different error messages,each of which includes different politeness strategies. In the study, firstly users’ politeness orientations were elicited and then participants were asked to interact with websites including pre-determined problems. When users encountered problems, the system provided certain error messages representing one positive politeness strategy (i.e. joke), one negative politeness strategy (i.e. a simple apology), and a mechanical message for the error (i.e. the page is temporarily unavailable). The findings of the study showed that users who deal with social events with polite expressions preferred to receive apologetic messages significantly more than mechanical or joke messages, and they preferred apologetic messages significantly more than those messages that are less oriented to polite expressions.

The article also calls out how an apologetic tone as opposed to a negative tone impacts the perception that users of them selves and how a positive apologetic perception can help in enhancing positive performance

De Laere, Lundgren, and Howe(1998) compared human-like versus machine-like interaction styles of computer interfaces.They did not observe a significant difference between the different styles in terms of users’self-appraisals. The findings of the study also demonstrated that negative feedback affects the self-perceptions of the participants differently than positive feedback.

Tzeng (2004) examined whether apologetic feedback affects users’ performance perception in the computerized environment. This study suggested that users may not expect computers to be polite, but apologetic statements made the subjects feel better about their interactions with the program.

The research paper Computer Apology: The Effect of the Apologetic Feedback on Users in Computerized Environment also calls out why apologetic negative feedback ties into user experience from a social aspect

The use of apologetic statements with an error message contributes the human-computer interaction. If we consider that the main aim of the user centered design is to create an environment for users in which they feel themselves comfortable, use of apologetic statements in the user interface design become a very important issue. Moreover, in human-human interaction, one of the more important, may be the most, issues is to behave in a respectful manner. In most of the societies when a person does not behave in a respectful manner or makes a mistake towards the other person, apologizing is the traditional and the most effective way in order to overcome the problem. Similarly, this study shows that most of the subjects thought that apologetic feedbacks do not seem awkward to them and 95% of them receiving apologetic feedback felt that apologetic feedback seemed sensitive to them. Here, it seems that subjects find it interesting to confront with respectful behavior such as apologizing when they encounter an error caused by computers’ inability as if they encounter a problem in human interaction. The findings of this study indicate that representing the affective state of a person in the interface design is very important in human-computer interaction because people are more sympathetic to see emotional aspects in the interface such as, sensitivity, respect, and feeling of humanity. Therefore, these results might be used as evidence for the claim that computers’ offering apologetic statements to the users can substantiate the idea of real user centered design.

On the flip side Microsoft recommends using sorry or an apologetic tone only when a serious error has occurred:

Use the word “sorry” only in error messages that result in serious problems for the user (for example, data loss or inability to use the computer). Don’t apologize if the issue occurred during the normal functioning of the program (for example, if the user needs to wait for a network connection to be found).

share|improve this answer
2  
I find this rational interesting. I'm curious though if there's an unintended effect of training the user to blame your program even why they are doing something improperly. Would they start to get the attitude of "this program is junk?" –  Andy Jan 4 '13 at 20:56
36  
Not to sound like a troll, but uxmatters.com can be taken more seriously if their site wasn't so hideous and hard on the eyes! –  ajacian81 Jan 5 '13 at 1:31
1  
@LightnessRacesinOrbit, the OP's scenario is a selling opportunity. The particular user is attempting to use an aspect of the program for which she isn't licensed. Why not treat her with respect? Of course, a system might say "would you like a 5-day trial of this feature?" –  Ollie Jones Jan 5 '13 at 15:00
1  
@Mervin Wow, you added a lot of additional research in your last two edits. Very nice! +1 –  3nafish Jan 6 '13 at 21:18
2  
@MANCHUCK Try two positives to make a negative: "You think you can access that? Yeah, right." ;) –  ZeroOne Jan 8 '13 at 15:18

While Mervin's answer is excellent, I would go beyond saying it is "acceptable" or "preferred". I would say you "must" use an apologetic tone for one very good reason: if the user is making a mistake, it is because the user does not understand the rules or logic of the system. That is not the fault of the user! It is responsibility of the system to accurately explain the logic of the system to users. A user error then is a mismatch between what the user thinks should be done, and what the system allows to be done.

While one would never be this wordy, if we spell it all out, your apologetic error message is: "I'm sorry that the user interface of this program, your past experience with it, or experience with other similar programs, have led you to believe that you could take such an action at this time, but you can't because ...."

Specific to the case mentioned: the user thought that access might be available. You are apologizing for the misunderstanding that the user had, because the system had not previously communicated that the permission was not available.

What does it mean to say that an error might be the user's fault? Users don't go and do things that they know will not work (that would just waste their own time). The only reason they do something wrong is because they don't know it won't work. If the user does not know something, isn't it really the fault of the system for not making this transparent? Regardless of how obvious a programmer might think it is, the vast majority of the time a mistake is the fault of the system, so write your error messages in accordance, and you will have happier users.

share|improve this answer
1  
Welcome to the UX Stack Exchange! Your first post is well-reasoned. +1 –  3nafish Jan 5 '13 at 0:02
3  
Well written, but I disagree. I don't see why we must pander to users. In this day and age everyone seems to feel entitled to blame somebody else for all of their problems, but if my users are snooping around areas to which they have no access, that's their fault, not my system's. Let them take some damned responsibility for their actions! –  Lightness Races in Orbit Jan 5 '13 at 14:26
15  
The user is not there to use the software, they are there to perform some form of work or achieve a goal. The software is simply one of the tools they will use to do so. The tool is apologizing because it cannot do what the user has asked of it in order to achieve their goal. Some users may just be testing boundaries, but in my software I'd rather give an accurate message to the percentage of users using my software properly than a slap on the wrist because of some other percentage that are testing the boundaries (but also paying me money). –  Tarwn Jan 5 '13 at 18:59
    
+1 @Burnt Too Many Times - I agree. If the program or computer failed to perform a valid task, then an apology is in order. If the error was the fault of the user, then "I'm sorry" is still appropriate as a way to express "regret. Like: "I regret to inform you that (I'm sorry) you can't do that". While I think it would "always" be appropriate to use an apologetic tone, it should not be "overdone". –  Kevin Fegan Jan 6 '13 at 21:59
5  
@LarsH Agreed. There are users who are "criminally uninformed" but two thoughts (1) they are really very few, and (2) they are not the important part of the market. The butler who is polite to the rogue is simply proving the ability to be polite to the master. And this term "pandering": Is Apple pandering to the user because they make an IPhone that can be used without reading ANY manual? Anyone concerned with user experience is aiming for the "ideal" which is a program that can be used without having to read a manual. Every user, then, risks being uninformed. –  AgilePro Jan 7 '13 at 19:13

Taking a step back: Why was this feature made available (visible) to the user in the first place?

If it is a feature not available to a specific user (or user class), hide it.

If it is a premium feature that you'd like to upsell - do so.

History export is a great way to backup your data, but is available on premium accounts only. Get in touch with your administrator and ask them to upgrade your account to Premium.

Regarding downtime or errors (when the responsibility falls solely on the application), I feel tone is secondary to knowing that:

The issue has been logged and that a warm body somewhere knows you are having issues.

There is someone available for me to contact.

I can try again.

Something went terribly horribly wrong!
We've logged the error.
Please try again or contact help@application.com and we'll get back to you as soon as possible.

share|improve this answer
6  
Why doesn't this answer have more upvotes? Max is spot on, there should be absolutely no way for the user to try something that will fail 100% of the time! –  codesparkle Jan 5 '13 at 17:29
19  
The problem with hiding options, is that there is no way to learn WHY they are hidden. Again, if you see the purpose of a good UI is help train the user, then consider what a person does to do something new. They look around for something (a menu or button) that looks close and they try that. An error message explaining WHY they can't do it, can be quite important for learning. e.g. "You can't connect to the server because no password is set". If you simply hide the connect button you would never learn this. –  AgilePro Jan 6 '13 at 2:34
3  
But you can gray-out this menu item and add a tooltip explaining why it is not accessible –  danilo2 Jan 6 '13 at 23:58
5  
@danilo2 I would never rely on a tooltip to convey critical information like this. It's highly likely that the majority of users will never see it and will therefore remain confused, frustrated, or simply ignorant. I find Burnt Too Many Times's comment a more pragmatic approach. –  Mal Ross Jan 9 '13 at 9:17

I don't find apologies very humanizing from a computer, any more than an automated hold system for a phone network makes me feel like my call is important by saying, "Your call is very important to us! Please stay on the line for the next available representative."

I don't think the apologies are the main issue here. Far more important is that they are clear enough to help the user resolve the issue without overwhelming them.

A good error message is perfectly detailed about exactly what caused the problem and how to fix it. It's also perfectly understandable and doesn't stress out the user by using jargon they don't understand.

Of course, these two goals conflict with one another. Telling the user that a fatal exception has occurred while discombobulating the kernel at line 47 and there is a memory dump logged is extremely helpful to a developer, but it's completely lost to the user and introduces more stress to the user than the error itself. Yet it's equally, if not more obnoxious to have an error message that says, "Sorry! I screwed up. Sorry about that!" As a user, how am I supposed to know what went wrong? How can I begin to go about solving my issue?

It comes down to a compromise that is considerate of the user (Are they probably a power user? Is that fact up in the air? Is English their first language? etc.).

I find it preferable to avoid the fluff and clutter of apologies for mistake the user brought on themselves, and instead write error messages that are genuinely considerate of the user by making it perfectly clear how to resolve it.

share|improve this answer
    
I disagree with your first sentence. Good software looks and feels like it was designed by professional and helpful people, in the same way that a dish from an excellent restaurant has appetizing, humanizing elements. A good waiter or chef would apologize if the customer finds the experience wanting in any way. I think of software apologies as coming from the programmer or UI designer, not my computer. –  Roy Tinker Jan 7 '13 at 18:21
    
@RoyTinker I think that's a valid point, but it depends on the execution. I think that users will treat you software the way they do an automated phone system unless you convince them otherwise by means of mastery of the craft (like a chef). –  Ben Mordecai Jan 7 '13 at 18:34
1  
discombobulate: (transitive, humorous) To throw into a state of confusion; to befuddle or perplex. –  Peter Jan 9 '13 at 7:11

Yes, error messages should apologize whenever it's remotely plausible to do so. People will ascribe human emotions to computers, so the computers should be as polite as possible, regardless of whether they're actually at fault.

A chapter "Bringing Affect to Human Computer Interaction" has a section on apologetic feedback:

Nielsen (1998) argued that when auser encounters a problem and receives an error message, it should include a simple apologetic statement that the reason of the error is the limitation of the interface to execute the command for the intended task, not user’s action. [...]

Tzeng (2004) showed that the subjects inapologetic feedback groups did not perceive their performance and ability as better than those in non-apologetic groups. He further demonstratedthat computer users might not expect computers to be polite; yet apologetic statements makesubjects feel better about their interaction withthe program. Based on the idea that participants’ politeness orientations might have an influenceon their perceptions of apologetic computer error messages, Tzeng (2006) conducted another study investigating users’ perceptions about online systems containing three different error messages, each of which includes different politeness strategies. He elicited users’ politeness orientations and asked them to interact with websites, each of which contains pre-determined problems. Upon encountering problems, users are provided with certain error messages representing three different politeness strategies, which were positive politeness strategy (i.e. joke), negative politeness strategy (i.e. a simple apology), and a mechanical message for the error (i.e. the page is temporarily unavailable). The findings revealed that users,who use polite expressions while dealing withsocial events, preferred apologetic messages significantly more than both other mechanicalor joke messages and other users, who are less oriented to polite expressions.

There's also some evidence that users' reactions to the mood of error messages depends upon their own mood. If you know what mood the users are likely to be in, you may be able to use that to structure your error feedback instead.

share|improve this answer

Be natural, this can be annoying if you're apologizing too often, write your message in plain language—like a human talking to another human. If error is caused by you (your app, your server e.t.c.) add apology, otherwise leave just statement of fact and how to resolve the issue.

For example:

  • "Sorry, we couldn't send your message because of [some] problem on our server. Please try again."
  • "We couldn't send your message; please fill email field."

Another one:

  • "Sorry, you don't have permission to access this feature anymore; your balance was low and we downgraded your plan."
  • "You don't have access to this feature; it's available only in our Extended plan."

When you remove all these "sorry"s from message - you make it shorter, which means that user can read and resolve the issue faster. If you give clear instructions and issue can be fixed easily - no one needs the apologies.

share|improve this answer
3  
because of problem on our server I despise messages like this. Tell me what actually happened. I can't do anything at all with "there's a problem on the server". What problem?! Your other examples are great, though. –  Lightness Races in Orbit Jan 5 '13 at 14:27
    
@LightnessRacesinOrbit I completely agree. I added that quote as an example - just to emphasize that you should always apologize when action is caused by app, but missed overall text of error message. Thx! –  Dmitry Semenov Jan 5 '13 at 15:28
    
This is one of the differences between Linux and Windows. Linux error messages give you details to fix the problem, whereas Windows error messages give you user-friendly, but administrator-unfriendly error messages. The solution? Use both: "There was a problem on the server. Technical information: no DNS lookup for domain xyz.com". –  barrycarter Jan 5 '13 at 20:29
5  
@barrycarter Or even just "There was a problem on the server. [details]" Then when you click on "[details]" it expands to show (using your example) "no DNS lookup for domain xyz.com". Progressive disclosure. Spare those who don't care from even seeing the technical stuff (most of the time it will only confuse them) but make it readily available to those who want to see it. Best of both worlds. –  Michael Kjörling Jan 5 '13 at 21:20
    
@MichaelKjörling: I have for many years wished that communications APIs could be better designed to programs know what was going on, so they could in turn inform their users. Not trying to get over-technical, but to distinguish between "The computer has requested the address of xyz from .com but got no response", or "There is no xyz in .com", "the computer has received the address of example.com but, but connection requests yield no response", or "a connection response to example.com was refused". –  supercat Jul 17 at 16:28

I believe two rule-of-the-thumbs can be applied in most cases:

  1. If the user made a mistake, don't apologize for its mistake. Rather instruct how to avoid/correct the problem next or in the future. Provide help resources if possible/applicable.

  2. If the problem was caused by the program, make a simple apology for the inconvenience out of courtesy, but it's more important to inform the user what actually happen, what will happen next, what can be done to fix it, offer the chance to assist correcting the problem (ie. issue an error report) and so forth.

share|improve this answer

Software doesn't have feelings or an ego, but people do. If, for example, you make a mistake while using AMEX's merchant PBX, the system says "Sorry, my mistake" in a pleasant human voice. This could be seen as patronizing by some, but it's also humanizing and in my opinion very smart.

It's better to err on the side of being too apologetic, rather than too controlling or mean (eg "Enter a number, stooopid!", or worse: no feedback at all). Humans are often hierarchical, and unfortunately, apologies are often viewed as submissive actions. People want to feel like they are better than the computers they use, so an apology will work in this direction.

In short, looking at this as a matter of "who's at fault?" is a very logical way to approach a very non-logical problem, that is: how do you help a user feel OK about an obstacle in the flow of using your software?

share|improve this answer

Like all UX decisions consider the context of use. I do not think apologize for anything the user did is appropriate, but if the system or application became unavailable to them or failed due to a non-user issue (outage, infrastructure failure and so on), then it's worth considering, provided it comes with other useful information about the issue being known, ETA of fix, what to do next, workarounds - anything to keep the user going or to bring them back.

On a related point what does drive users nuts is not an apology or lack of, but the instructions to contact a system administrator. Lots of users cannot do that, or even know how or what a system admin is! Better in such application failure cases to do the contacting for them (say to a help desk or support team) and tell them it's done, relying using incident management and automatic logging. Then tell the user how to proceed, if their work is safe, what the incident number is, how to share it, and so on.

Perhaps this will be of use: https://blogs.oracle.com/userassistance/entry/unexpected_errors_are_they_ever_expected_anyway

share|improve this answer

Your statement seems about fine to me. It's not too apologetic in nature, as it shouldn't be. And, you very well compliment the apology with the relevant solution in the very next line. Apology becomes necessary in some situations because some error messages come out as too blunt and negative that can end up demotivating the users.

Even if it's the user's fault, you don't want to come out as rude and insensitive since the software can never know how a specific user will take a specific error message particularly when it hampers his productivity. Adding a small apology and a possible solution neutralises the whole error message and let's the user concentrate on the solution rather than the problem.

share|improve this answer

Depends on site or apps intent. Do you want the user to feel they are at a loss? For example; do you want them to upgrade their account to increase revenue? I'm thinking users often will upgrade when faced with a feeling of loss or "doing without" a feature. An error message is another valuable opportunity to make an impression on the user. If the error is not important to the goals of the interface; I would not make a bigger "thing" out of the error. Quickly note the error and help get the user back to the intended task.

share|improve this answer

Working for SAS company, I would say being apologetic is necessary, assuming that you're not assuming fault.

With companies like Starbucks, Apple, and Zappos out there, people don't care whose fault it was, as long as it's not theirs. The consumer, end-user, and purchaser is king or queen.

So don't apologize if your app/site deletes all their data... That's welcoming a lawsuit wit open arms, but people love to feel like the world is their oyster. And if you have an apologetic message WITH a means to quickly find a solution -- go for it.

share|improve this answer

Apologetic tone helps maintain proper, human-like, communication. Something that shouldn't be underestimated!

Interaction with an interface should always be compared to face-to-face human conversation. Imagine that you're trying to buy a train ticket with a discount that doesn't apply to your case. Would you rather like to hear "Access forbidden!" from the cashier, than something informative and polite?

Besides, if user can access a place that you can't let him interact with - that's in many cases designer's fatal error. Nothing to blame user for.

share|improve this answer
    
I second the implicit advice that thought ought to be given to designing a system/site so that users cannot attempt access to features that users do not have access to. –  Michael E2 Jan 6 '13 at 14:04

Yes, be pollite to the user, but keep in mind that users do not read - especially the text in the middle. So make sure the actual information is easy to spot. And it can be a real pain when you have forms with several error messages and every single one beginning with "Sorry ..." or "Oops ..."

share|improve this answer

you should apologize for not giving them a link or phone number or any other way to "contact their administrator for assistance"

The user is left wondering "administrator of what?", "my office administrator or the one at your company?"

share|improve this answer

protected by JonW Jan 5 '13 at 17:35

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.