4 ms·

Never met an app that could actually feel sorry (maybe someday?). This type of behaviour just feels artificial and inauthentic in most products. If your makin

by bhawks 3y ago

Never met an app that could actually feel sorry (maybe someday?). This type of behaviour just feels artificial and inauthentic in most products. If your making an error message effort I'd focus first on being clear, concise and actionable. Try to establish some expectations for the user so they know how and when things will be resolved, ensure you're monitoring and alerting is appropriate to hold yourself accountable to those expectations. If you really need to apologize, a human should do it.

firtoz 3y ago
Introducing our latest apology boss feature. Every time an error happens, you get a popup with an AI version of our boss bowing down in shame.
vanderZwan 3y ago
The app didn't write the error message, the people implementing the app did. Any error message is just as much a form of communication between them and me as it is between the app and me.
- jxf 3y ago
  But we can't identify which human wrote the message. There's a huge difference between a push notification that says: > Flight UA569 has been canceled. We apologize for the inconvenience and we will rebook you on the next available flight. and one that says: > Flight UA569 has been canceled. I apologize for the inconvenience and I will rebook you on the next available flight. — Alice
  - vanderZwan 3y ago
    I'm not sure what you are trying to say. Yes, there is a difference in the two examples you gave, although it would have been nice if you had been more specific about what you meant. What I notice is that the first option the apology comes from the company and the people in it, and intended to imply they see it as their responsibility to fix things. The second would imply that Alice is personally to blame for the cancellation and taking responsibility. Either are technically possible, although the latter seems very unlikely to ever happen. What I fail to see is what this has to do with the error messages. The example given was "Sorry, you do not have permission to access this feature. Please contact your administrator for assistance", which falls under the first form. This seems appropriate for a message representing a team of people who wrote the program, as well as the administrator. It also is quite representative of the apology style seen in such messages.
    - jxf 3y ago
      > I'm not sure what you are trying to say. Your remark was "The app didn't write the error message, the people implementing the app did". I responded by saying that you can't tell who the human is. > it would have been nice if you had been more specific about what you meant It's the very first sentence: you can't identify the human. I showed an example of why it's different when you can tell that there is a human involved working with you specifically.
      - vanderZwan 3y ago
        Are you suggesting that the hypothetical anonymous apology by the flight company in your example is insincere and shouldn't have been given? Because if not it changes very little about the actual point, which is whether such apologies make sense or not.
- bhawks 3y ago
  Is it possible to apologize in advance? For me an apology requires one party listen and understand the problem the other party experienced. They then convey that understanding back to the other party along with taking some amending action. The author of the error message is communicating in a unidirectional manner to the the receiver with limited context of the overall interaction. That is a difficult scenario to attempt to apologize from.
  - vanderZwan 3y ago
    Well the example error message just did, didn't it? I see no reason why one would not be able to anticipate unavoidable inconveniences in advance and write an automated apology for it.
  - deleted 3y ago
    [deleted]
gary_0 3y ago
It depends on the message, but a "Sorry" can set the right tone so a user doesn't feel "yelled at". Omitting the pleasantry might make things seem too terse. Sorry, your e-mail failed to send. Your e-mail failed to send. I much prefer the first one. Software intended for typical end users should have a respectful tone and avoid sounding like it's blaming the user. On the other hand, something like strerror()'s output (eg. "Bad file number") is appropriately terse due to being meant more for programmers.
- bhawks 3y ago
  Both these error messages fail the "where do we go from here?" test - disrespecting the user with requiring open ended work on their part. Having some breadcrumbs to get back to the right track is much more valuable than flowery wordings. Eg: Message too large - failed to send email. Network unavailable - failed to send email. Subscription expired - failed to send email. Unexpected service outage - https://email.io/status https://email.io/status - failed to send email.
  - gary_0 3y ago
    The details of the error weren't the point of my example. And being that terse sounds like you're barking orders at the user. Once again, shortness is fine for programmer communication, but personally for an end user just going about their day I would avoid such an impertinent tone.
cqqxo4zV46cp 3y ago
A lot of software copy writing becomes so much easier when you ditch the silly facade of ‘the computer’ saying things. Instead treat the whole scenario as the software acting as an agent of the organisation, with the copy being written by a human on behalf of the organisation. So, a lot of “we…”. This in my opinion makes software a whole lot more friendly, human, and overall just…usable. It gives way more opportunity to convey things in a way that doesn’t leave people scratching their heads and reaching for the knowledge base, where a lot of orgs are a lot less scared of writing like robots. The issue though is the amount of software written by people in America, or should I say California, where there is a very distinct ‘fake-politeness’. I genuinely can’t tell whether or not they know how much it sticks out like a sore thumb to everyone else. In this case, the software being more human backfires, because allowing the human to shine through is just allowing us to see the shitty fake-happy way that humans at the organisation think that the organisation should be talking to customers. TL;DR: writing like a human is good, unless your humans are bad.

by bhawks 3y ago

firtoz 3y ago

Introducing our latest apology boss feature. Every time an error happens, you get a popup with an AI version of our boss bowing down in shame.

vanderZwan 3y ago

The app didn't write the error message, the people implementing the app did. Any error message is just as much a form of communication between them and me as it is between the app and me.

jxf 3y ago
But we can't identify which human wrote the message. There's a huge difference between a push notification that says: > Flight UA569 has been canceled. We apologize for the inconvenience and we will rebook you on the next available flight. and one that says: > Flight UA569 has been canceled. I apologize for the inconvenience and I will rebook you on the next available flight. — Alice
- vanderZwan 3y ago
  I'm not sure what you are trying to say. Yes, there is a difference in the two examples you gave, although it would have been nice if you had been more specific about what you meant. What I notice is that the first option the apology comes from the company and the people in it, and intended to imply they see it as their responsibility to fix things. The second would imply that Alice is personally to blame for the cancellation and taking responsibility. Either are technically possible, although the latter seems very unlikely to ever happen. What I fail to see is what this has to do with the error messages. The example given was "Sorry, you do not have permission to access this feature. Please contact your administrator for assistance", which falls under the first form. This seems appropriate for a message representing a team of people who wrote the program, as well as the administrator. It also is quite representative of the apology style seen in such messages.
  - jxf 3y ago
    > I'm not sure what you are trying to say. Your remark was "The app didn't write the error message, the people implementing the app did". I responded by saying that you can't tell who the human is. > it would have been nice if you had been more specific about what you meant It's the very first sentence: you can't identify the human. I showed an example of why it's different when you can tell that there is a human involved working with you specifically.
    - vanderZwan 3y ago
      Are you suggesting that the hypothetical anonymous apology by the flight company in your example is insincere and shouldn't have been given? Because if not it changes very little about the actual point, which is whether such apologies make sense or not.
bhawks 3y ago
Is it possible to apologize in advance? For me an apology requires one party listen and understand the problem the other party experienced. They then convey that understanding back to the other party along with taking some amending action. The author of the error message is communicating in a unidirectional manner to the the receiver with limited context of the overall interaction. That is a difficult scenario to attempt to apologize from.
- vanderZwan 3y ago
  Well the example error message just did, didn't it? I see no reason why one would not be able to anticipate unavoidable inconveniences in advance and write an automated apology for it.
- deleted 3y ago
  [deleted]

gary_0 3y ago

It depends on the message, but a "Sorry" can set the right tone so a user doesn't feel "yelled at". Omitting the pleasantry might make things seem too terse. Sorry, your e-mail failed to send. Your e-mail failed to send. I much prefer the first one. Software intended for typical end users should have a respectful tone and avoid sounding like it's blaming the user. On the other hand, something like strerror()'s output (eg. "Bad file number") is appropriately terse due to being meant more for programmers.

bhawks 3y ago
Both these error messages fail the "where do we go from here?" test - disrespecting the user with requiring open ended work on their part. Having some breadcrumbs to get back to the right track is much more valuable than flowery wordings. Eg: Message too large - failed to send email. Network unavailable - failed to send email. Subscription expired - failed to send email. Unexpected service outage - https://email.io/status https://email.io/status - failed to send email.
- gary_0 3y ago
  The details of the error weren't the point of my example. And being that terse sounds like you're barking orders at the user. Once again, shortness is fine for programmer communication, but personally for an end user just going about their day I would avoid such an impertinent tone.

cqqxo4zV46cp 3y ago

A lot of software copy writing becomes so much easier when you ditch the silly facade of ‘the computer’ saying things. Instead treat the whole scenario as the software acting as an agent of the organisation, with the copy being written by a human on behalf of the organisation. So, a lot of “we…”. This in my opinion makes software a whole lot more friendly, human, and overall just…usable. It gives way more opportunity to convey things in a way that doesn’t leave people scratching their heads and reaching for the knowledge base, where a lot of orgs are a lot less scared of writing like robots. The issue though is the amount of software written by people in America, or should I say California, where there is a very distinct ‘fake-politeness’. I genuinely can’t tell whether or not they know how much it sticks out like a sore thumb to everyone else. In this case, the software being more human backfires, because allowing the human to shine through is just allowing us to see the shitty fake-happy way that humans at the organisation think that the organisation should be talking to customers. TL;DR: writing like a human is good, unless your humans are bad.