Quelle est la formulation recommandée pour un message d'erreur générique
Quelle serait la meilleure formulation pour un message d'erreur générique?
Avec generic error message Je veux dire un message pour une erreur qui s'est produite mais il n'y a pas de détails sur ce qu'est l'erreur ou comment la récupérer.
Il sera utilisé exclusivement en tant que solution de secours lorsqu'il n'est pas possible pour déterminer l'erreur, soit parce que le serveur n'a envoyé aucun détail supplémentaire, soit parce qu'il y a un délai "probable" ... et d'autres cas Edge similaires.
Il devrait viser à minimiser la quantité de frustration/colère.
J'ai lu quelques discussions, mais aucune ne semble pertinente à 100%
- Recommandations pour de bonnes ressources sur la rédaction de bons messages d'erreur
- Messages d'erreur d'application (Web) standardisés? [Fermé] Il s'agit en fait d'une correspondance très étroite, mais les rapports d'erreur sont hors de portée dans mon cas
- Quels seront les meilleurs notifications et messages d'erreur?
- Avis de message d'erreur (pour les tâches asynchrones/en arrière-plan)
- Messages d'erreur génériques/vagues à transmettre aux utilisateurs de spam?
Un bon message d'erreur devrait:
- Faites-vous savoir quel est le problème.
- Vous faire sentir comme si vous pouviez y faire quelque chose.
- Parlez comme un humain, et soyez une extension cohérente de la personnalité du reste de l'application.
Pour les messages d'erreur génériques, vous ne pouvez pas faire grand-chose sur le premier point, mais vous pouvez faire quelque chose sur les deux autres.
Faites quelque chose qui permet à l'utilisateur de savoir que le problème n'est pas ignoré. Laissez-les prendre des mesures telles que soumettre les journaux ou envoyer un rapport d'erreur. Vous pouvez également leur faire savoir qu'une action automatique a déjà été effectuée et que votre personnel technique a automatiquement été informé que cette erreur s'est produite et y travaille.
Ensuite, dans la façon dont vous leur dites, vous devez exprimer le message en parler humain et garder le ton cohérent avec le reste du site (ce qui devrait être approprié pour votre public). Si votre site est ludique, utilisez un message d'erreur ludique. S'il s'agit d'un service médical, rendez-le totalement professionnel.
Voici donc des exemples:
Oops! Quelque chose a mal tourné!
Aidez-nous à améliorer votre expérience en envoyant un rapport d'erreur
ou
L'application a rencontré une erreur inconnue.
Cela ne semble pas avoir affecté vos données, mais notre personnel technique a été automatiquement informé et examinera cela avec la plus grande urgence.
ou
Merde, les gerbilles ont de nouveau arrêté de courir! Quelqu'un a été envoyé pour les frapper avec un bâton tranchant.
Selon le ton de l'application, vous pouvez utiliser quelque chose comme:
"Oups! Un problème est survenu." - Envoyez un rapport d'erreur pour nous aider à améliorer votre expérience
"L'application a rencontré une erreur inconnue." - Envoyer un rapport d'erreur pour diagnostic.
Google chrome utilise une erreur générique: "Google Chrome se ferme de façon inattendue." - Ignorer, signaler ou rouvrir).
Vous pouvez suivre les dialogues avec ce que mesure préventive vous avez pris, "Le système doit s'arrêter" "Le service redémarré" ou tout ce qui rentre dans le contexte.
Je pense qu'il est également important de parler avec un ton un peu apologétique (pas exagéré) lorsque cela est possible.
Pas comme de réelles excuses, mais plutôt comme une expression de regret. Un simple 'Désolé pour le dérangement ...' ou 'Désolé cela ne fonctionne pas ...' peut aider l'utilisateur à sentir que ce n'est pas son propre faute (même si elle l'est).
Modifier:
@norabora - Des recherches pour confirmer pourquoi un tel ton pourrait être important? Ou des exemples de zones actuellement utilisées? -
En partie, c'est quelque chose que je ressens fortement. Mais il y a beaucoup de discussions et de recherches à ce sujet.
Voici un autre article sur ux.stackexchange: Les messages d'erreur doivent-ils s'excuser? qui contient de nombreuses références sur le sujet.
Et cet article est un résumé du sujet.
Voici une étude sur Computer Apology: The Effect of the Apologetic Feedback on Users in Computerized Environment [PDF].
En outre, voici une étude sur L'effet des messages d'erreur apologétiques et des états d'humeur sur l'auto-évaluation des performances des utilisateurs d'ordinateurs. .
Il y a quelques citations pertinentes de ces études et d'autres articles et documents de recherche dans cette réponse sur ux.stackexchange.
Le meilleur message d'erreur concerne toujours le contexte, probablement le meilleur message serait:
- Pertinent pour l'utilisateur
- Honnête (vous pouvez faire des blagues mais cela doit être évident)
- Pas gênant pour l'utilisateur
- Par conséquent, blâmer les systèmes et non l'utilisateur
- Lui dire quoi faire ensuite (ou le rendre évident)
- Explicite sur la façon de le faire
Aux autres excellentes réponses, je veux juste ajouter que je pense que le mot "inconnu" devrait être évité dans les messages d'erreur destinés aux utilisateurs, car cela donne l'impression que personne a une idée de ce qui s'est passé. Si l'utilisateur n'est pas responsable de la résolution du problème, il n'est pas nécessaire de le porter avec les détails, mais le message devrait impliquer que les personnes qui sont responsables ont les détails. (Même si ce n'est pas vrai à 100%.)
Ben a un très bon article sur la rédaction de messages d'erreur
Un message d'erreur générique doit être:
"Le serveur a rencontré une erreur lors du traitement de la demande."
Veuillez réessayer, Désolé pour le problème.
Dans les tests utilisateurs de formulaires nous voyons souvent les gens devenir légèrement nerveux lorsque nous utilisons des mots négatifs dans les messages d'erreur - l'utilisation de mots comme "erreur" ou "interdit" a un effet subtil mais négatif sur l'expérience. Nous avons donc tendance à éviter les mots négatifs quand c'est la faute de l'utilisateur
- nous montrons que quelque chose s'est mal passé en utilisant une couleur appropriée (orange ou jaune) à côté du champ
- nous attendons avec impatience et disons "Veuillez remplir ce champ obligatoire" ou "Veuillez saisir un nombre compris entre 1 et 10".
Quand c'est le faute du système on utilise la règle générique:
- énoncer ce qui n'a pas fonctionné (soyez bref, les gens sont souvent d'accord pour savoir simplement qu'il y a eu une erreur technique)
- dire ce que l'utilisateur peut faire à ce sujet.
Nous avons tendance à utiliser des mots plus négatifs pour qu'il soit intuitivement clair que quelque chose s'est mal passé "Erreur: le système n'a pas pu récupérer xyz, [quelqu'un qui peut résoudre le problème] a été informé. Veuillez réessayer dans environ 10 minutes, désolé pour le désagrément"
Les réponses ci-dessus sont excellentes en ce qui concerne les erreurs où vous ne disposez pas de suffisamment d'informations pour déterminer le problème (par exemple, le serveur distant a renvoyé 500, cela n'aide pas à le dire aux utilisateurs), à savoir:
- Gardez-le amical
- Évitez le techno-jargon
- Notez que l'erreur a été enregistrée et qu'ils peuvent ajouter plus d'informations s'ils pensent qu'elle est pertinente.
Cependant,
Les délais d'attente doivent avoir leur propre message
Un délai d'attente probable peut être expliqué à l'utilisateur sans utiliser le "délai d'attente" de Word, par exemple, si vous vous connectez aux API Google Contacts:
Il nous faut beaucoup de temps pour entendre Google vous parler de vos contacts.
Devrions-nous réessayer ou passer à l'étape suivante ?
Sur la base des informations du livre de Donald Norman The Design of Everyday Things , que je recommande fortement, il est important de donner aux utilisateurs des commentaires sur ce qu'ils doivent faire en cas d'erreur. Un message d'erreur générique utile est: Sorry an error occurred. Please click here. Dans ce message, click here est un lien vers la page d'accueil où l'utilisateur peut redémarrer.