Les messages d'erreur doivent-ils s'excuser?
Nous avons une discussion sur notre équipe à propos d'un message d'erreur qui dit "Désolé, vous n'avez pas la permission d'accéder à cette fonctionnalité. Veuillez contacter votre administrateur pour obtenir de l'aide."
Est-il approprié d'utiliser le langage des "excuses" dans ce cas? Le raisonnement qui s'y oppose est qu'il serait plus approprié de "s'excuser" pour quelque chose qui serait considéré uniquement comme la "faute" de la demande, comme un temps d'arrêt. ("Désolé mais notre site est actuellement indisponible ... veuillez réessayer plus tard.")
La raison pour laquelle je crois qu'il est important d'avoir un ton d'excuse est de s'assurer que vous communiquez à l'utilisateur que, même si une erreur a été commise et qu'il interagit avec une machine ou une application dans ce cas, vous respectez toujours son action et vous humanisez l'erreur.
Pour citer ceci article de UXMatters :
"Vous allez afficher votre message d'erreur à une personne, alors écrivez-le dans le ton de la voix que vous utiliseriez si vous le disiez directement à la personne."
Je recommande également de lire cet excellent article, Dites-vous "non" quand vous pourriez dire "oui" dans vos formulaires Web? :
Les messages d'erreur semblent être une partie sans importance et incroyablement ennuyeuse de l'élaboration d'une expérience utilisateur. Mais la tonalité des messages d'erreur peut faire basculer l'expérience d'un abandon presque certain à une conversion.
L'article souligne que les messages d'erreur doivent porter un ton positif et donc une réponse d'excuse peut aider les utilisateurs à récupérer rapidement et à ne pas devenir immédiatement défensifs face à une erreur qu'ils auraient pu commettre.
Écrire des messages d'erreur qui portent un ton positif n'est pas sorcier. Suivez simplement quelques règles simples:
Tout d'abord, débarrassez-vous du jargon technique tel que "incompatible". La plupart des utilisateurs ne savent pas ce que cela signifie. Parlez-leur dans leur propre langue et non dans la langue de vos développeurs. Par exemple, "incompatible" se traduit par "ne fonctionne pas ensemble" en anglais simple.
N'utilisez pas de mots négatifs
Identifiez clairement l'erreur afin que l'utilisateur sache quoi corriger.
Donnez à l'utilisateur un aperçu de la façon dont le problème peut être résolu.
Mettez le blâme sur vous, pas sur l'utilisateur.
Je recommande également de consulter L'effet des messages d'erreur apologétiques et des états d'humeur sur l'auto-évaluation des performances des utilisateurs d'ordinateurs pour une étude qui a analysé l'impact de l'utilisation de messages d'erreur apologétiques sur les états d'humeur des utilisateurs et comment les humains- comme les tons apologétiques sont efficaces dans les interfaces informatiques. Pour citer un extrait de l'article
Dans HHI, les excuses sont généralement utilisées pour exprimer des regrets (Leech, 1983; Schlenker et Darby, 1981) ou pour soulager la colère des individus en raison de leur désapprobation de l'action des autres.En d'autres termes, les excuses atténuent la frustration et la colère lorsque les tentatives d'interaction échouent. , Nielsen (1998) fait valoir que les messages d'erreur répondant à l'action de l'utilisateur de l'ordinateur devraient inclure une simple déclaration d'excuse lorsque la raison de l'erreur est la limitation de l'interface de l'ordinateur pour effectuer la tâche prévue. Tzeng (2006) a mené une étude sur la perception qu'ont les utilisateurs des systèmes en ligne contenant trois messages d'erreur différents, chacun comprenant des stratégies de politesse différentes. Dans l’étude, les orientations de politesse des utilisateurs ont tout d’abord été dégagées, puis les participants ont été invités à interagir avec des sites Web, y compris des problèmes prédéterminés. Lorsque les utilisateurs ont rencontré des problèmes, le système a fourni certains messages d'erreur représentant une stratégie de politesse positive (c'est-à-dire une blague), une stratégie de politesse négative (c'est-à-dire de simples excuses) et un message mécanique pour l'erreur (c'est-à-dire que la page est temporairement indisponible). Les résultats de l'étude ont montré que les utilisateurs qui traitent d'événements sociaux avec des expressions polies préféraient recevoir des messages d'excuses beaucoup plus que des messages mécaniques ou de plaisanterie, et ils préféraient les messages d'excuses beaucoup plus que les messages moins orientés vers des expressions polies.
Le article explique également comment un ton apologétique par opposition à un ton négatif affecte la perception que les utilisateurs d'eux-mêmes et comment une perception apologétique positive peut aider à améliorer les performances positives
De Laere, Lundgren et Howe (1998) ont comparé les styles d'interaction humains à des machines d'interfaces informatiques, mais n'ont pas observé de différence significative entre les différents styles en termes d'auto-évaluation des utilisateurs. Les résultats de l'étude ont également démontré que la rétroaction négative affecte les perceptions de soi des participants différemment de la rétroaction positive.
Tzeng (2004) a examiné si la rétroaction apologétique affecte la perception des performances des utilisateurs dans un environnement informatisé. Cette étude a suggéré que les utilisateurs ne peuvent pas s'attendre à ce que les ordinateurs soient polis, mais les déclarations d'excuses ont permis aux sujets de se sentir mieux dans leurs interactions avec le programme.
Le document de recherche Computer Apology: The Effect of the Apologetic Feedback on Users in Computerized Environment explique également pourquoi les commentaires négatifs apologétiques sont liés à l'expérience utilisateur sous un aspect social
L'utilisation de déclarations apologétiques avec un message d'erreur contribue à l'interaction homme-ordinateur. Si nous considérons que l'objectif principal de la conception centrée sur l'utilisateur est de créer un environnement pour les utilisateurs dans lequel ils se sentent à l'aise, l'utilisation des déclarations d'excuses dans la conception de l'interface utilisateur devient un problème très important. De plus, dans l'interaction homme-homme, l'un des plus importants, peut-être le plus, est de se comporter de manière respectueuse. Dans la plupart des sociétés, lorsqu'une personne ne se comporte pas de manière respectueuse ou fait une erreur envers l'autre personne, s'excuser est le moyen traditionnel et le plus efficace pour surmonter le problème. De même, cette étude montre que la plupart des sujets pensaient que les commentaires apologétiques ne leur semblaient pas gênants et 95% d'entre eux recevant un retour apologétique estimaient que le retour apologétique leur semblait sensible. Ici, il semble que les sujets trouvent intéressant de se confronter à des comportements respectueux tels que des excuses lorsqu'ils rencontrent une erreur causée par l'incapacité des ordinateurs comme s'ils rencontraient un problème d'interaction humaine. Les résultats de cette étude indiquent que la représentation de l'état affectif d'une personne dans la conception de l'interface est très importante dans l'interaction homme-ordinateur, car les gens sont plus sympathiques à voir les aspects émotionnels de l'interface tels que la sensibilité, le respect et le sentiment d'humanité. Par conséquent, ces résultats pourraient être utilisés comme preuve pour affirmer que les ordinateurs proposant des déclarations d'excuses aux utilisateurs peuvent étayer l'idée d'une conception centrée sur l'utilisateur réel.
D'un autre côté Microsoft recommande en utilisant désolé ou un ton d'excuse uniquement lorsqu'une erreur grave s'est produite:
Utilisez le mot " désolé " uniquement dans les messages d'erreur qui entraînent de graves problèmes pour l'utilisateur (par exemple, perte de données ou incapacité à utiliser l'ordinateur). Ne vous excusez pas si le problème s'est produit pendant le fonctionnement normal du programme (par exemple, si l'utilisateur doit attendre qu'une connexion réseau soit trouvée).
Bien que la réponse de Mervin soit excellente, j'irais au-delà de dire qu'elle est "acceptable" ou "préférée". Je dirais que vous "devez" utiliser un ton d'excuse pour une très bonne raison: si l'utilisateur fait une erreur, c'est parce que l'utilisateur ne comprend pas les règles ou la logique du système. Ce n'est pas la faute de l'utilisateur! Il est de la responsabilité du système d'expliquer avec précision la logique du système aux utilisateurs. Une erreur utilisateur est alors un décalage entre ce que l'utilisateur pense devoir faire et ce que le système permet de faire.
Bien que l'on ne soit jamais aussi verbeux, si nous expliquons tout cela, votre message d'erreur d'excuse est: "Je suis désolé que l'interface utilisateur de ce programme, votre expérience passée avec celui-ci ou votre expérience avec d'autres programmes similaires , vous ont amené à croire que vous pouviez entreprendre une telle action en ce moment, mais vous ne pouvez pas parce que .... "
Spécifique au cas mentionné: l'utilisateur pensait que l'accès pourrait être disponible. Vous vous excusez pour le malentendu de l'utilisateur, car le système n'avait pas précédemment indiqué que l'autorisation n'était pas disponible.
Que signifie dire qu'une erreur pourrait être la faute de l'utilisateur? Les utilisateurs ne vont pas faire des choses qu'ils savent ne fonctionneront pas (cela leur ferait perdre leur propre temps). La seule raison pour laquelle ils font quelque chose de mal, c'est parce qu'ils ne savent pas que cela ne fonctionnera pas. Si l'utilisateur ne sait pas quelque chose, n'est-ce pas vraiment la faute du système pour ne pas avoir rendu cela transparent? Indépendamment de la façon dont un programmeur peut penser que c'est évident, la grande majorité du temps, une erreur est la faute du système, alors écrivez vos messages d'erreur en conséquence, et vous aurez des utilisateurs plus heureux.
Prendre du recul: Pourquoi cette fonctionnalité a-t-elle été mise à la disposition (visible) de l'utilisateur en premier lieu?
S'il s'agit d'une fonctionnalité non disponible pour un utilisateur (ou une classe d'utilisateurs) spécifique, masquez-la.
S'il s'agit d'une fonctionnalité premium que vous souhaitez vendre, faites-le.
L'exportation d'historique est un excellent moyen de sauvegarder vos données, mais n'est disponible que sur les comptes premium. Contactez votre administrateur et demandez-lui de mettre à niveau votre compte vers Premium.
En ce qui concerne les temps d'arrêt ou les erreurs (lorsque la responsabilité incombe uniquement à l'application), je pense que le ton est secondaire à savoir que:
Le problème a été enregistré et un corps chaud sait quelque part que vous rencontrez des problèmes.
Il y a quelqu'un que je peux contacter.
Je peux réessayer.
Quelque chose a terriblement mal tourné!
Nous avons enregistré l'erreur.
Veuillez réessayer ou contacter [email protected] et nous vous répondrons dans les plus brefs délais.
Je ne trouve pas les excuses très humanisantes d'un ordinateur, pas plus qu'un système de mise en attente automatisé pour un réseau téléphonique ne me donne l'impression que mon appel est important en disant: "Votre appel est très important pour nous! Restez en ligne pour le prochain représentant disponible. "
Je ne pense pas que les excuses soient le principal problème ici. Plus important encore, ils sont suffisamment clairs pour aider l'utilisateur à résoudre le problème sans le submerger.
Un bon message d'erreur est parfaitement détaillé sur la cause exacte du problème et comment le résoudre. Il est également parfaitement compréhensible et ne stresse pas l'utilisateur en utilisant un jargon qu'il ne comprend pas.
Bien sûr, ces deux objectifs sont en conflit l'un avec l'autre. Dire à l'utilisateur qu'une exception fatale s'est produite lors de la décomposition du noyau à la ligne 47 et qu'un vidage de mémoire est enregistré est extrêmement utile pour un développeur, mais il est complètement perdu pour l'utilisateur et introduit plus de stress pour l'utilisateur que l'erreur elle-même. Pourtant, il est également, sinon plus désagréable d'avoir un message d'erreur qui dit: "Désolé! J'ai foiré. Désolé à ce sujet!" En tant qu'utilisateur, comment suis-je censé savoir ce qui n'a pas fonctionné? Comment puis-je commencer à résoudre mon problème?
Cela se résume à un compromis qui est respectueux de l'utilisateur (sont-ils probablement un utilisateur expérimenté?.
Je trouve préférable d'éviter les excuses et l'encombrement des excuses pour les erreurs que l'utilisateur a commises sur lui-même, et d'écrire à la place des messages d'erreur qui sont véritablement attentifs à l'utilisateur en indiquant clairement comment le résoudre.
Oui, les messages d'erreur doivent s'excuser quand cela est plausible. Les gens attribueront les émotions humaines aux ordinateurs , donc les ordinateurs devraient être polis, en particulier aux utilisateurs qui s'attendent à ce que les gens soient polis.
Par exemple, les sites Web conçus pour les personnes âgées bénéficieraient de messages très polis à la fois
- pour montrer que le site et non l'utilisateur est en faute
- pour s'aligner sur les attentes sociales de ces utilisateurs. (Je fais l'hypothèse que les personnes âgées sont plus susceptibles de s'attendre à de la politesse dans une interaction sociale normale entre humains.)
Un chapitre " Apporter un effet à l'interaction homme-machine " comporte une section sur les commentaires apologétiques (c'est moi qui souligne):
Nielsen (1998) a soutenu que lorsqu'un utilisateur rencontre un problème et reçoit un message d'erreur, il devrait inclure une simple déclaration d'excuse indiquant que la raison de l'erreur est la limitation de l'interface pour exécuter la commande pour la tâche prévue, pas l'action de l'utilisateur. [...]
Tzeng (2004) a montré que les sujets des groupes de rétroaction apologétique ne percevaient pas leur performance et leur capacité comme meilleurs que ceux des groupes non apologétiques. Il a en outre démontré que les utilisateurs d'ordinateurs ne s'attendaient pas à ce que les ordinateurs soient polis; pourtant, les déclarations d'excuses permettent aux sujets de se sentir mieux dans leur interaction avec le programme. En se basant sur l'idée que les orientations de politesse des participants pourraient avoir une influence sur leur perception des messages d'erreur informatique apologétiques, Tzeng (2006) a mené une autre étude examinant les perceptions des utilisateurs sur les systèmes en ligne contenant trois messages d'erreur différents, chacun comprenant des stratégies de politesse différentes. Il a suscité les orientations de politesse des utilisateurs et leur a demandé d'interagir avec des sites Web, dont chacun contient des problèmes prédéterminés. En cas de problème, les utilisateurs reçoivent certains messages d'erreur représentant trois stratégies de politesse différentes, à savoir une stratégie de politesse positive (c'est-à-dire une blague), une stratégie de politesse négative (c'est-à-dire de simples excuses) et un message mécanique pour l'erreur (c'est-à-dire que la page est temporairement indisponible). Les résultats ont révélé que les utilisateurs, qui utilisent des expressions polies lorsqu'ils traitent avec des événements sociaux, préféraient les messages apologétiques beaucoup plus que les autres messages mécaniques ou blagues et les autres utilisateurs, qui sont moins orientés vers les expressions polies.
Il existe également des preuves que les réactions des utilisateurs à l'humeur des messages d'erreur dépendent de leur propre humeur . Si vous savez dans quelle humeur les utilisateurs sont susceptibles d'être, vous pourrez peut-être l'utiliser pour structurer vos commentaires d'erreur à la place.
Soyez naturel, cela peut être ennuyeux si vous vous excusez trop souvent, écrivez votre message dans un langage simple - comme un humain parlant à un autre humain . Si une erreur est causée par vous (votre application, votre serveur e.t.c.) ajoutez des excuses, sinon laissez juste une déclaration de fait et comment résoudre le problème.
Par exemple:
- "Désolé, nous n'avons pas pu envoyer votre message en raison d'un problème sur notre serveur. Veuillez réessayer."
- "Nous n'avons pas pu envoyer votre message; veuillez remplir le champ e-mail."
Un autre:
- "Désolé, vous n'avez plus la permission d'accéder à cette fonctionnalité; votre solde était faible et nous avons déclassé votre plan."
- "Vous n'avez pas accès à cette fonctionnalité; elle n'est disponible que dans notre plan étendu."
Lorsque vous supprimez tous ces "désolé" du message - vous le raccourcissez, ce qui signifie que l'utilisateur peut lire et résoudre le problème plus rapidement . Si vous donnez des instructions claires et que le problème peut être résolu facilement - personne n'a besoin des excuses.
Je crois que deux règles générales peuvent être appliquées dans la plupart des cas:
Si l'utilisateur a fait une erreur, ne vous excusez pas pour son erreur. Dites plutôt comment éviter/corriger le problème prochain ou futur. Fournir des ressources d'aide si possible/applicable.
Si le problème a été causé par le programme, faites des excuses simples pour la gêne occasionnée par courtoisie, mais il est plus important d'informer l'utilisateur de ce qui se passe réellement, de ce qui se passera ensuite, de ce qui peut être fait pour y remédier , offrir la possibilité d'aider à corriger le problème (c.-à-d. émettre un rapport d'erreur) et ainsi de suite.
Le logiciel n'a pas de sentiments ni d'ego, mais les gens en ont. Si, par exemple, vous faites une erreur en utilisant le PBX marchand d'AMEX, le système dit "Désolé, mon erreur" d'une voix humaine agréable. Cela peut être considéré comme condescendant par certains, mais c'est aussi humanisant et à mon avis très intelligent.
Il vaut mieux se tromper par excuse, plutôt que par trop de contrôle ou de méchanceté (par exemple, "Entrez un nombre, stupide!", Ou pire: pas de retour du tout). Les humains sont souvent hiérarchisés et, malheureusement, les excuses sont souvent considérées comme des actions soumises. Les gens veulent se sentir meilleurs que les ordinateurs qu'ils utilisent, donc des excuses vont dans ce sens.
En bref, considérer cela comme une question de "qui est en faute?" est une façon très logique d'aborder un problème très non logique, à savoir: comment aider un utilisateur à se sentir bien face à un obstacle dans le flux d'utilisation de votre logiciel?
Le ton apologétique aide à maintenir une communication appropriée et humaine. Quelque chose qui ne doit pas être sous-estimé!
L'interaction avec une interface doit toujours être comparée à une conversation humaine en face à face. Imaginez que vous essayez d'acheter un billet de train avec une remise qui ne s'applique pas à votre cas. Souhaitez-vous plutôt entendre "Accès interdit!" de la caisse, que quelque chose d'informatif et de poli?
De plus, si l'utilisateur peut accéder à un endroit avec lequel vous ne pouvez pas le laisser interagir - c'est dans de nombreux cas une erreur fatale du concepteur. Rien à blâmer pour l'utilisateur.
Oui, soyez attentif à l'utilisateur, mais gardez à l'esprit que les utilisateurs ne lisent pas - en particulier le texte au milieu. Assurez-vous donc que les informations réelles sont faciles à repérer. Et cela peut être une vraie douleur lorsque vous avez des formulaires avec plusieurs messages d'erreur et que chacun commence par "Désolé ..." ou "Oups ..."
Votre déclaration me semble à peu près correcte. Ce n'est pas de nature trop apologétique, comme cela ne devrait pas l'être. Et, vous complimentez très bien les excuses avec la solution pertinente dans la ligne suivante. Des excuses deviennent nécessaires dans certaines situations, car certains messages d'erreur apparaissent comme trop directs et négatifs qui peuvent finir par démotiver les utilisateurs.
Même si c'est la faute de l'utilisateur, vous ne voulez pas paraître impoli et insensible, car le logiciel ne peut jamais savoir comment un utilisateur spécifique prendra un message d'erreur spécifique, en particulier lorsqu'il entrave sa productivité. L'ajout de petites excuses et d'une solution possible neutralise l'ensemble du message d'erreur et permet à l'utilisateur de se concentrer sur la solution plutôt que sur le problème.
Dépend de l'intention du site ou des applications. Voulez-vous que l'utilisateur se sente perdu? Par exemple; voulez-vous qu'ils améliorent leur compte pour augmenter leurs revenus? Je pense que les utilisateurs se mettent souvent à niveau lorsqu'ils sont confrontés à un sentiment de perte ou de "se passer" d'une fonctionnalité. Un message d'erreur est une autre occasion précieuse de faire une impression sur l'utilisateur. Si l'erreur n'est pas importante pour les objectifs de l'interface; Je ne ferais pas une plus grande "chose" de l'erreur. Notez rapidement l'erreur et aidez l'utilisateur à revenir à la tâche prévue.
Comme toutes les décisions UX, tenez compte du contexte d'utilisation. Je ne pense pas que m'excuser pour tout ce que l'utilisateur a fait est approprié, mais si le système ou l'application est devenu indisponible pour eux ou a échoué en raison d'un problème non-utilisateur (panne, panne d'infrastructure, etc.), alors cela vaut la peine d'être considéré, à condition qu'il vienne avec d'autres informations utiles sur le problème connu, ETA du correctif, que faire ensuite, solutions de contournement - tout pour garder l'utilisateur en marche ou pour le ramener.
Sur un point connexe, ce qui motive les utilisateurs n'est pas une excuse ou un manque, mais les instructions pour contacter un administrateur système. Beaucoup d'utilisateurs ne peuvent pas faire cela, ni même savoir comment ou ce qu'est un administrateur système! Mieux dans de tels cas d'échec d'application, faites le contact pour eux (par exemple à un service d'assistance ou à une équipe de support) et dites-leur que c'est fait, en utilisant la gestion des incidents et la journalisation automatique. Dites ensuite à l'utilisateur comment procéder, si son travail est sûr, quel est le numéro de l'incident, comment le partager, etc.
Peut-être que cela sera utile: https://blogs.Oracle.com/userassistance/entry/unexpected_errors_are_they_ever_expected_anyway
Peut-être que la justification n'est pas la meilleure voie à suivre en ce qui concerne les messages d'erreur. Si nous suivons une logique universelle, oui, nous ne devrions pas nous excuser pour quelque chose qui n'est pas de notre faute.
Cependant, nous devons toujours mettre en valeur l'approche centrée sur l'utilisateur dans le but final de mettre l'utilisateur à l'aise, quoi qu'il arrive. À cet égard, une approche apologétique est la meilleure solution.
Pensez à ce que l'utilisateur ressent à ce moment:
"Merde, je ne suis pas autorisé à utiliser cette fonctionnalité!"
Une erreur est un moment crucial où vous pouvez facilement perdre un visiteur, c'est pourquoi vous devez traiter la situation très attentivement, en pensant à toutes les implications cognitives et psychologiques. C'est ce qui compte vraiment, pas la logique de la vie quotidienne.
Que ce soit de sa faute ou non, en cas d'erreur, l'utilisateur se sentira frustré. Lorsque vous vous sentez frustré, vous voulez les excuses de quelqu'un. Oui, vous blâmez tout le monde et tout ce qui vous entoure, mais vous-même.
C'est puéril, mais j'avoue que ça m'est aussi arrivé. Lorsqu'une candidature m'a échoué (à cause de mon erreur) et s'est excusée, cela m'a vraiment fait sourire et m'a fait réfléchir:
"Très bien, je te pardonne. Je sais que tu n'as rien fait de mal, de toute façon."
Si vous visez à tout prix un certain corectness politique et que vous ne voulez pas vous excuser pour quelque chose qui n'est pas de votre faute, envisagez un ton plus neutre, comme:
" Malheureusement , vous n'êtes pas autorisé à accéder à cette fonctionnalité."
Je trouve la Parole "malheureusement" cruciale. Sinon, cela ressemblerait à une incrimination, qui chassera l'utilisateur frustré en une seconde:
"Vous n'êtes pas autorisé à accéder à cette fonctionnalité." (ajoutez un point d'exclamation et vous ne verrez plus cet utilisateur)
Je trouve le message entier trop formel d'une manière ou d'une autre (c'est vrai, cela dépend du contexte de votre application). Je choisirais quelque chose de court et de drôle qui transmet le message de manière non robotique. Cela semble simple, mais il est très difficile de trouver de tels textes, si vous vous entraînez de cette façon, afin d'éviter d'autres dilemmes comme celui-ci:
Vous devez également fournir une explication possible de l'erreur et quelques moyens de la récupérer. Cela réduira tellement la frustration de l'utilisateur!
Travailler pour SAS entreprise, je dirais que faire des excuses est nécessaire, en supposant que vous ne supposez pas la faute.
Avec des entreprises comme Starbucks, Apple et Zappos, les gens se moquent de savoir à qui la faute, tant que ce n'est pas la leur. Le consommateur, l'utilisateur final et l'acheteur est roi ou reine.
Alors ne vous excusez pas si votre application/site supprime toutes leurs données ... C'est accueillir un procès à bras ouverts, mais les gens aiment sentir que le monde est leur huître. Et si vous avez un message d'excuse AVEC un moyen de trouver rapidement une solution - allez-y.
vous devez vous excuser de ne pas leur avoir fourni un lien ou un numéro de téléphone ou toute autre manière de "contacter leur administrateur pour obtenir de l'aide"
L'utilisateur se demande "administrateur de quoi?", "Mon administrateur de bureau ou celui de votre entreprise?"