Should error messages apologize?
ux.stackexchange.com
ux.stackexchange.com
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.
regrettable or deplorable; unfortunate; sympathy
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".
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.
It's a fine line between that at being annoying, though.
I just found (when looking for the exact quote) blogpost about the same idea[1].
[1]: http://www.swinkmag.com/archive/aaronstern.html I wonder whether
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."
I can imagine a scenario where you want the users to be aware of the feature and have the administrator act as a filter gateway.
Another scenario is when your application structure is too rigid and hiding the feature would cost much more than adding an error message.
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.
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".
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?
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).
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).
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.
"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.
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.
The medium answer is: media = real life
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.
[0] http://en.wikipedia.org/wiki/The_Media_Equation
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.
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.
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...
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.
I think sincerity is the most important thing.
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'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.
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]
For others interested in Dalvik, I did find a couple of useful links:
http://www.android-x86.org/
http://stackoverflow.com/questions/1297678/how-do-i-make-isolated-dalvik
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.
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.
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.
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
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.
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.
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.