I'd say to forget about apologising when the user was at fault and tell them what they can do to resolve it. No need to turn it into a personalised essay.
For example, you could say:
"I'm sorry you cannot delete this document"
A better message may be:
"You cannot delete this document when someone else is viewing it"
and even better may be:
"You cannot delete this document when someone else is viewing it. Click here to see who is viewing this document".
If you want to apologise when the user does something wrong, then build software that doesn't cause the user to generate an error situation in the first place. By apologising you are supporting the fact that it was okay for the user to do what they did or that they were treated unfairly, when it isn't, because the user still can't do it.
If the user wasn't to blame, then by all means apologise and reassure them that the issue will be addressed. Also clearly explain what the expectations are from now on, such as, loss of data.
That's my take on it, and I wont be apologising for that. But if you want to know whether you should apologise or not, you need to do some usability testing and see if it has any impact on the goals of the software and the user experience.
It does not automatically mean to be an apology. In these cases, I am pretty sure users don't see it as one either. I always saw it as more sympathy than an apology.
As for telling users what they can do to resolve it, sure but they are not mutually exclusive. You can still say "Sorry, you cannot delete this document when someone else is viewing it".
Agreed. Users care more about getting the task done then having an emotional relationship with the system. To inject sympathy into what need only be informative/instructive, is to call attention to the user's ignorance in fabricating false expectations of the system. That's more offensive than anything else.
Only in the case of the system inadvertently failing to meet the expectations it made (e.g. database server inaccessible) would apologetic messaging be considered.
"Sorry, all our customer care representatives are busy on other calls. Your call is important to us..." Has anyone - anyone! - ever been mollified by this kind of apology? Straight from the Sirius Cybernetics Corporation's Genuine People Personalities( first against the wall when the revolution comes)
Error messages which apologize fall into the same bucket. Scripted apologies add insult to injury. Just tell me what's wrong and how to fix it, don't bother pretending to be human.
Whatever qmail might do wrong, I always smile when I get a mail bounce from a qmail server explaining that it tried everything but couldn't send my email, and that it's sorry. Just an anecdote, but I think a friendly tone humanises things and takes a bit of the frustration away.
It's a fine line between that at being annoying, though.
Relatedly, what's the value of an error message apologising ? Should the message be connected to a human feeling the "sorry" emotion ?
Personally I prefer less dramatic and to the point tone. At least it's not fake: "Hey, this feature is locked down and not accessible by everyone. Have a chat with your administrator if you want it to be unlocked."
It's a trade off. It may be something the user expects to be able to do, but for whatever reason doesn't have permission. In that case it's better to say "You don't have permission to do 'foo', please contact your administrator if this is incorrect." (no need for "Sorry..." either, IMO). Then they know what's going on, instead of just wondering "Where the hell is the 'foo' button..."
Or maybe they can use the feature in some situations but not others. For example they can edit some records but only view others. In the second case, having a visible but inoperative "Save" button may be a better user experience than the save button being completely hidden.
Particularly in the case of an application that interacts with users external to the entity/organization that "owns" the app, you can look at communication between the app and the user as communication between the application's owner and the user that has been automated: if you had a live person representing the company and a client asked for something policy didn't allow you to provide them, the usual practice and common courtesy would be to initially respond with something along the lines of "I'm sorry, I can't provide that information to you." The fact that the communication comes through a computer system shouldn't change the message the company wants to convey.
I think there is a strong causation between the way products address their users (not only software, but also cars, appliances, physical forms), and the perceived value of that product.
Step into a luxury car and ask yourself, why do I see this car as luxurious? Sure, it looks nice, but it will also convey a message that says: "When we created this car, we really tried to make you feel comfortable, treated well and respected".
This might seem like over stretching the question in the link, but underneath lies the question: "How hard do we want to try to serve the end user".
> luxury car
> "When we created this car, we really tried to make you feel comfortable, treated well and respected"
Do you really believe that? Do you think that cheaper car makers try to make me feel unconfortable, treated badly, etc.? Or at least don't care about it?
I think the most part of this feeling could very well be some suggested feeling. You buy an expensive car, therefore it must be good, and the ads say nothing else, so you feel comfortable because you have been told you should.
Many recent luxury cars do not give a damm for the owners convenience, it shows very well in the fact that most do not have a simple audio plug so you can plug your ipod or phone. Just like we have been told the chemical smell they add on detergents is the smell of clean clothes, and just like we are told that the more toothpaste we put on the brush the cleaner the teeth (in fact, only the brushing is useful, no toothpaste at all is ok too).
There is fine line between creating a positive experience for the end user, and suggesting a positive experience. Some examples:
Cars: No, cheaper car makers will not degrade the experience, but they will direct less attention to the perceived experience by the end user, also because their margin is lower.
Your point about the audio plug: It annoys me too, but this depends on the target audience. Do they value an audio plug over a clean dashboard?
Toothpaste: Here a false claim is made. That does not convey respect to the user at all.
What complicates these discussions is that, for example on HN, they are discussed with people who often value features over a smooth experience. But I argue, that for the average high income user, the experience, the treatment is an important factor, next to features.
And to come back to the OP, treating your users properly will enhance the value of your application to this group.
> Do they value an audio plug over a clean dashboard?
"Clean dashboard" is the apparent reason, but there is in fact no difficulty to have a clean dashboard with an audio plug, or put the plug in the gunbox.
There is another reason behind it, an industry agreement, a friend working in this field evocated it in front of me. They just really do not care if it is convenient or not.
Other examples: In supermarket, they put the water bottle packs near the end, because they do not want clients to come, buy a trolley of water, and go home. (It is like that in France, not sure in US) So everyone is extremely annoyed and has to put water packs over eggs, strawberries, clothes, and many other fragile stuff.
Next example: we are told that files are "inconvenient and messy" and many UX guys swallowed it straight. But it is just a big lie. Files are badly needed in Apple products, and I heard some are uplownloading their pdf attachements through dropbox just to use them on their phone or tablets.
Back to cars: I own a Suzuki minivan, very cheap, but in many way more confortable than my previous car (a WV Golf) just because the seat is higher on the road and the inside volume is much bigger. Real comfort is not made of leather and crafted door sounds (yes, cars door slping sound is crafted carefuly), it is made of room around the head and further view on the road.
Back to the OP: treating your users properly is obviously good, but adding too much sweetener on error messages is not the way to treat them properly.
You could essentially say, that whenever anything does not work, we (the developers) have failed to meet the user's expectation. So we should try to convey this message as gentle as possible - right?
Yes, we should, but my trail of thought tried to address the deeper (or tangential) rationale for humanized error messages. My argument was that if you humanize error messages, you are increasing the service towards your end user. You convey a message that says "I see that something limits the use of the application, how can I help solve this".
In general, the hierarchy of error prevention and solving should be this:
0. Treat the end user as a normal human being (obvious? well, I wish it was!)
1. Limit the steps a user has to take to a minimum, but no less then is required to execute the main goal of the application.
2. Focus steps as much as possible on doing something that satisfies a needed input by the user (i.e. minimize program management by the user)
3. Try to stop an error from happening before it occurs or asap. (Example: The stop sign when you drag a file in Windows where it can't be dragged, validation per form step).
3. When an error occurs, show a concise, friendly error-message, with is tells the user how to fix the issue or prevent it (if it can be done by the end user).
4. The level of apology should be linear to effect of the error: if the error makes the user feel disrespected, it stops him from finishing the task or delays him.
(i.e. apologise a lot if you application crashes, but a little if an e-mail address does not validate).
One of the answers contained this hypothetical error message: "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 ...."
Yes, they should. More importantly though, they should offer options.
When you call your cellular carrier to complain about something, you surely want them to apologize and offer you options. If they told you 'We experienced an error. What's next?' you'd be rightfully pissed. Why should software be held to inferior standards?
Controlling how your company communicates with customers in person is hard. If you want good results, you'll have to hire great service talent and let them give customer cases lots of attention. Contrast that to putting more thought into how your app fails. Even a few days of focus on friendly, empowering failures will give you much of the same results.
Take one easy win. Instead of 'Error: looks like you have a network problem', try 'Sorry, looks like you have a network problem. Can we help you somehow? [Email us]'
With one more line of text and a button, you've given your customer a clear sense that you're there for her when she has problems. We've been doing this for years. The feedback we've gotten, and the relationships we've established with customers have been invaluable.
An error message is text. It's not an algorithm, logic, data structure, or source code. It may seem obvious, but the point is it's not a software development question, and there is no best practice that will answer it correctly in all situations. It's a question of human interaction and communication. The correct answer will always depend on the circumstances.
The longer answer is there's an interesting an influential bit of scientific work that might shed some light on this issue, and incidentally, it is also not mentioned in the stackexchange link above.
The book is "The Media Equation: How People Treat Computers, Television, and New Media Like Real People and Places." by Byron Reeves [0]. The follow-up work to this is found in "The Man Who Lied to His Laptop: What Machines Teach Us About Human Relationships", also with Clifford Nass and Corina Yen.
It is often the case that psychology studies simply confirm what our own intuition tells us. How often have we looked at a psychology study and said, "Duh! Of course that would be the case." It is much rarer to see psychology studies that would yield results completely contrary to what we would expect, and this is what makes the work of Nass et. all so exciting. The most surprising thing about these experiments were that participants, even expert computer users, were adamant that they could not possibly be influenced by a computer who has a female voice vs. a male voice, or a computer that praises versus criticizes, or heck, a computer that has the same physical color that is the favorite color of the user, but it turns out that they are.
It is not that people anthropomorphize computers; they clearly recognize that computers are not in fact people -- but hundreds of thousands of years of evolution have hard-wired many of our responses, which are often largely automatic even when our interactions are with computers instead of other humans.
As others have indicated, there is a fine line, however. Do you recall the sad Mac? [1] This was an example of the Media Equation that was applied well -- you and I and even naive computer users know that computers don't __actually__ get sick, but you can't help but think so as your first reaction when you see that icon; you might even feel a little sympathetic. Simultaneously, have you ever seen the Clippy Office Assistant? [2] It's notorious for being one of the worst examples in history of affective computing design; unlike the sad Mac, it actually will elicit anger, the opposite of what we would want in a computing experience.
That seems intuitive to me. When the computer is affective, I assume the programmer is talking to me.
Similar to cars, where we ascribe the physical properties of the vehicle to its owner, so we think that a tiny lady in a giant SUV is a big aggressive being, or that a truck driver is slow and dull.
> When the computer is affective, I assume the programmer is talking to me.
It's interesting that you mention this, and the researchers thought that the same effect might be happening. So they controlled for this, but I don't remember the experimental details. It turned out, however, that the majority of participants were __not__ treating the software messages as a proxy for the programmer who developed that software.
I actually feel the same way you do to some extent, especially as a computer programmer, but they have data, and I have only anecdotes.
My philosophy on this is that there is a very high value on being brief. Even one less word can make the difference between a message seeming to long too bother with and actually getting read.
Sounding like a human will add more value than removing every word you can. Unless, of course your target audience isn't human or doesn't like to read human generated text (a trait that everyone seems to aquire while in front of a UNIX system).
Sounding like a human will make people read more of your message than simply making it brief, and understand it better. Also, it will make people like it more.
But that doesn't means that you should apologize. You must give all your messages the same personality, and some kinds of personality just don't apologize...
I very much agree that there is a balance to be struck, and messages designed for people to read should be composed with that fleshy audience in mind. However, if a polite message goes unread, the effort was in vain. And getting computer users who are not techies to actually read messages is very difficult. I've found brevity helps a lot. To your point, though, it may be the case that if all messages were a bit more empathetic, people would stop ignoring them so often.
From a dumb user POV, I would say that it depends on frequency.
If I see a one off apology, for a one off issue, perhaps with a mild sense of humour, then that's good, I like that. I might even have sympathy.
If, however, I see a regular, frequent issue and get the same apology over and over again, it begins to feel insincere, and that they are trying to cover an inherent issue with an insincere apology, or humour. I then begin to feel that they simply cant be bothered.
Yes, "I'm sorry" always carries the connotation of "this won't happen again" with it. If you are sorry all the time, it doesn't actually mean anything.
Like everywhere else the basic design principle of contrast also holds in the tone of error messages.
If you shout all the time, nobody will listen when you really mean it. Likewise, if you are sorry all the time, nobody will take your apology serious.
I don't think "I'm sorry" always carries the connotation of "this won't happen again".
"I'm sorry" has two very different uses -- it can mean, roughly, either "I accept responsibility for this thing which is my fault" or "I regret this occurrence, independent of whose fault it is". When used in the former sense, it doesn't necessarily imply that there will be no recurrence, but certainly implies that the speaker will make an effort to prevent recurrence. When used in the latter sense -- which I'd argue would be the usual sense in which an error message would have to be understood -- it certainly does not imply even that there will be an effort to prevent recurrence.
An error message means that the user is doing something you haven't thought about. Focus your energy on what the user was trying to do and solve it. That way you will avoid the error message at all.
Simple example: one of the most common error messages are misspelled mail/password in order to authenticate. Have you thought on other ways of authentication that might be more straight forward? that can eliminate the error messages altogether.
That was my first thought when I saw the title. More ever -- if your industrial application is killing you, does it help that it apologizes in a soothing tone of voice?
I suppose it might: It might help prevent panic. I seem to recall there's been a lot of research into alarms and warnings in (fighter) jets when stalling, calling for eject etc -- to prevent the pilot from panicking, yet being promptly informed of the situation (as far as the system can "know" what is happening) and then be able to take correct action.
On another note, I recently went looking for the source code for the Dalvik VM, hoping to play with it under (desktop) linux, and found this very helpful link to the sourcecode on Google code:
https://android.googlesource.com/?p=platform/dalvik.git;a%3Dtree
"410. That’s an error.
The requested URL was not found on this server. That’s
all we know." [Picture of sad, broken robot]
Extremely annoying. I don't know if it would've helped much if it was worded differently. I guess the "that's all we know" is really annoying in this case, as the link is from Googles own Dalvik/Android wiki-page[1], so (somewhat unfairly) associating the Google team behind Android with the Google code logo/team -- it is obvious that that is not "all we know" (we, being Google in this case).
For others interested in Dalvik, I did find a couple of useful links:
Providing options, with a professional and courteous tone, to rectify the situation is different than apologizing. Polite expressions of options are necessary.
But apologizing? As in, "expressing sympathy"? IMO, no.
Humans do not get offended when their car doesn't start because it's out of gas and doesn't offer an apology. They still love their car, they will still continue to use it.
Humans do not get offended when they click to a cable channel that they aren't subscribed for and an expression of sympathy isn't displayed. They will continue watching television and subscribing to cable.
Humans do not get offended when the hold a hammer by the "business end" and try to drive a nail in with the handle, and an "I'm sowwy!" flag doesn't pop out of it. They will go on to learn the correct way to use it.
Computers are merely another inanimate object. Ultimately it's a system that serves the user when used correctly. A bank teller on the other hand, should apologize because there is the appearance of discretion in the bank teller's undesired response. Applications have no discretion in their actions. Humans are fine accepting that their actions led to an undesirable outcome, especially when avenues of correction are explained. Constant expressions of sympathy are annoying at best, and at worst can plant the seed of mistrust in the design and value of the system.
This doesn't hold when it's reasonable to hold the developers at fault for the undesired outcome. For example, if a feature was removed or redesigned without fair notice, an apology might be appropriate. In this case, they're failing to meet a certain expectation that had previously been set.
Update:
Upon further reflection, I recognize why I feel so strongly about this. I've worked on many public-facing applications before, from finance to social media. In each case, the use of apologetic or sympathetic expressions matched the site designer's personal belief in the value of the system and the correctness of the design. Where they had also expressed doubts about the success of the project, apologetic error messages were standard. Where they believed the project was well-designed and, if used correctly, would benefit the end-user, merely professional messages were used.
I now find myself inadvertently inferring such levels of confidence from all application messaging/copywriting.
> Humans do not get offended when their car doesn't start because it's out of gas and doesn't offer an apology.
> Humans do not get offended when they click to a cable channel that they aren't subscribed for and an expression of sympathy isn't displayed.
> Humans do not get offended when the hold a hammer by the "business end" and try to drive a nail in with the handle, and an "I'm sowwy!" flag doesn't pop out of it.
Well, I think you should reevalutate that info. Except for the second case, if people know they shouldn't get the show, people do in fact get offended by those innanimate objects. To the point of yelling to them.
I agree. I know I've certainly been offended by inanimate or even virtual objects. Closed source libraries with bugs or convoluted APIs are some of the most offensive things I've ever encountered.
But either the system was buggy (or the product was faulty or cheaply made, like a hammer that breaks on its first use), or the user simply used it incorrectly. Both can be phrased in terms of expectations. In the first, the developers failed to meet the expectations of the system (either explicitly set through marketing or usage manuals, or implicitly through interface design). In the second, the user ignored design cues and fabricated incorrect expectations, which the system then did not meet. I will say only the first case deserves apologetic tone, while most replies to the link are arguing that the second case deserves apologetic tone.
Why a system is responsible, or should show sympathy, for a user's ignorance of design cues is beyond me. I argue that most users prefer to only get the task done, and care more about whether the error messaging includes corrective advice than any apology. In fact, injecting apologetic, sympathetic emotion into an objective transaction only seeks to call attention to the user's ignorance and errant fabrication of expectations. Now that's offensive.
The content of error messages depends on who's going to be seeing those messages.
An "industrial-strength" C compiler like GCC has terse error messages, for example:
prgm.c:2:1: error: expected declaration or statement at end of input
A C parser on a website that teaches C to beginning programmers, however, should present more descriptive error messages.
That same website's server logs will probably have much more terse, unfriendly error messages because those will only be seen by the site administrators.
That's a really interesting topic and one I have not yet considered for my own applications - which is a shame.
I would probably stick with the apologetic approach. The rationale being that apologizing once too often will have a far less negative effect than not apologizing when appropriate.
IIRC that philosophy was also discussed in Dale Carnegie's "How to win friends and influence people".
I don't know the right answer in this particular case, but I have had long, interesting discussions about this whole thing in the past. A few off the cuff thoughts rooted in those discussions: I think a better goal is to fix the problem, make amends, and avoid having any reason to apologize. Apologies tend to read as admission of guilt. If you don't amend the problem but you keep apologizing every time it happens, you are behaving like a stereotypical abusive spouse. In other words, if apologies without solutions are normal behavior for your company, you are, in fact, guilty and the customer is not really being unreasonable to want to treat you like their bitch.
I don't know about all error messages, but the crash reports should certainly do... Or rather they should be humane, to the point, somewhat apologetic and with a bit of humor. In that order. I have a lot of bug reports received over the years that said that "I never submit crash reports, but yours was refreshingly different, so here's your stack dump".
Depends on the end user and the type of error. There's a difference between an error message on facebook, and an error in a server-based command-line application. If every error says sorry, the word loses its impact.
Imo it would also depend on the culture from the user; I wouldn't be surprised that too much apologizing would come over as "weak" in some cultures. This might influence the impression of your product.
no, they should print out stack trace and other useful information, depending on the user.
UI has to be responsive not to viewport sizes but to types of users. Some users prefer programmable interface. Some prefer button clicks. Error messages should be different, too.
For example, you could say:
"I'm sorry you cannot delete this document"
A better message may be:
"You cannot delete this document when someone else is viewing it"
and even better may be:
"You cannot delete this document when someone else is viewing it. Click here to see who is viewing this document".
If you want to apologise when the user does something wrong, then build software that doesn't cause the user to generate an error situation in the first place. By apologising you are supporting the fact that it was okay for the user to do what they did or that they were treated unfairly, when it isn't, because the user still can't do it.
If the user wasn't to blame, then by all means apologise and reassure them that the issue will be addressed. Also clearly explain what the expectations are from now on, such as, loss of data.
That's my take on it, and I wont be apologising for that. But if you want to know whether you should apologise or not, you need to do some usability testing and see if it has any impact on the goals of the software and the user experience.