Pattern "Erreurs": Aide à la rédaction des messages d'erreurs

[djaumes]

à ranger dans "Patterns"
sur une page dédiée: "Erreurs"

Supprimer le texte présent dans "Actions régressives" sous la section d) Erreurs, le replacer ici:

Erreurs

Guidelines générales:

1. • Une erreur se produit lorsqu’un processus échoue ou que la donnée ne correspond pas à la demande. Elle doit être exprimée clairement pour que l’utilisateur sache quelle action mener pour la résoudre. Elle doit être représentée en rouge.
2. • Pour un processus, il faut exprimer la raison de l’échec et l’action à mener: « Le document n’a pas pu être chargé, veuillez réessayer. » Pour un champ de données, il faut indiquer le bon format de données ou rappeler quels champs sont vides/obligatoires: « Veuillez indiquer la date au format JJ/MM/AAAA. » ou « Veuillez compléter les champs obligatoires. ».
3. • Le rédactionnel ne doit jamais mettre en défaut l’utilisateur. Il doit permettre de comprendre pourquoi l’erreur a eu lieu et comment la résoudre.
4. • Préférer limiter le texte à deux lignes.

Exemples d'erreurs

Ces exemples donnent une raison claire et concise, ne mettent pas en défaut l'utilisateur (même lorsque ses droits sont insuffisants), leur donnent un moyen de résolution.

Erreur liée au fonctionnement attendu

Le montant du comptant n’a pas pu être calculé, le comptant doit être forcé par le siège.
Veuillez prendre contact avec le siège pour résoudre le problème.

Données mises à jour

Des données client ou portefeuille ne sont plus concordantes.
Veuillez créer un nouveau devis.

Raison non expliquée car trop technique/ non nécessaire

Le projet ne peut être repris.
Veuillez retourner dans Salesforce pour créer une nouvelle opportunité.

Droits insuffisants

Vous ne pouvez pas effectuer de remplacement.
L’agent général du client doit effectuer cette action.

Evènement bloquant

Les données du véhicule étant incomplètes, le remplacement est impossible.
Vous devez résilier le contrat et effectuer une Affaire Nouvelle.

Annexe : Rappel des critères d’usabilité de Bastien et Scapin sur la rédaction des erreurs :

1. GESTION DES ERREURS

a) Définition :
Le critère Gestion des Erreurs concerne tous les moyens permettant d’une part d’éviter ou de réduire les erreurs, et d’autre part de les corriger lorsqu’elles surviennent. Les erreurs sont ici considérées comme des saisies de données incorrectes, des saisies dans des formats inadéquats, des saisies de commandes avec une syntaxe incorrecte, etc. Trois sous-critères participent à la Gestion des Erreurs : Protection Contre les Erreurs, Qualité des Messages d’Erreurs et Correction des Erreurs.

b) Justification(s) :
Les interruptions provoquées par les erreurs ont des conséquences négatives sur l’activité des utilisateurs. De manière générale, elles rallongent les transactions et perturbent la planification. Plus les erreurs sont limitées, moins il y a d’interruptions au cours de la réalisation d’une tâche et meilleure est la performance.

2. PROTECTION CONTRE LES ERREURS

a) Définition :
Le critère Protection Contre les Erreurs concerne les moyens mis en place pour détecter et prévenir les erreurs d’entrées de données ou de commandes ou les actions aux conséquences néfastes.

b) Justification(s) :
Il est préférable de détecter les erreurs lors de la saisie plutôt que lors de la validation : ceci évite de perturber la planification.

Exemples de recommandations :

• Quand les utilisateurs terminent une session et qu’il y a un risque de perte de données, il doit y avoir un message le signalant et demandant confirmation de fin de session.
• Les labels de champs doivent être protégés.
• Les aires d’affichage doivent être protégés : les utilisateurs ne doivent pas pouvoir changer les informations contenues dans ces champs.
• Toutes les actions possibles sur une interface doivent être envisagées et plus particulièrement les appuis accidentels des touches du clavier afin que les entrées non attendues soient détectées.

c) Commentaire(s) :
Protection Contre les Erreurs vs Incitation
Plusieurs façons d’offrir une protection contre les erreurs sont possibles. On peut par exemple mettre en place un mécanisme automatique de vérification des entrées. Ainsi, au moment de la validation des entrées, un message d’erreur apparaît si le format d’entrée n’est pas conforme à ce qui est attendu. Il s’agit bien dans ce cas-ci du critère Protection Contre les Erreurs. Une autre façon consiste à fournir une information renseignant les utilisateurs sur le type de données attendues ou encore sur le format de ces entrées : il s’agit alors du critère Incitation. Ces deux mécanismes peuvent aussi coexister.

3. QUALITÉ DES MESSAGES D’ERREUR

a) Définition :
Le critère Qualité des Messages d’Erreur concerne la pertinence, la facilité de lecture et l’exactitude de l’information donnée aux utilisateurs sur la nature des erreurs commises (syntaxe, format, etc.) et sur les actions à entreprendre pour les corriger.

Justification(s) :
La qualité des messages favorise l’apprentissage du système en indiquant aux utilisateurs les raisons ou la nature de leurs erreurs et en leur indiquant ce qu’il faut ou ce qu’ils auraient dû faire.

Exemples de recommandations :

• Si l’utilisateur sélectionne une touche fonction non valide, aucune action ne doit en résulter, si ce n’est un message indiquant les fonctions appropriées à cette étape de la transaction.
• Fournir des messages d’erreurs orientés tâches.
• Utiliser des termes aussi spécifiques que possibles pour les messages d’erreur.
• Utiliser des messages d’erreur aussi brefs que possible.
• Adopter un vocabulaire neutre, non personnalisé, non réprobateur dans les messages d’erreur; éviter l’humour.

b) Commentaire(s) :
Qualité des messages d’erreur vs Incitation
Un message d’erreur, peut comporter des incitations sur la manière de corriger une erreur. Il s’agit là du critère Qualité des Messages d’Erreur et non pas du critère Incitation. L’Incitation concerne uniquement le guidage en situation normale.

Qualité des Messages d’Erreur vs Lisibilité
Quand les messages d’erreur ne sont pas adéquats, même du point de vue lexical, il s’agit du critère Qualité des Messages d’Erreur, et non du critère Lisibilité. Le critère Qualité des Messages d’Erreur concerne toutes les caractéristiques des informations relatives aux erreurs des utilisateurs.

Qualité des Messages d’Erreur vs Concision
Le critère Concision ne s’applique pas aux messages d’erreurs. Lorsque ces derniers ne sont pas suffisamment succincts, il s’agit du critère Qualité des Messages d’Erreur.

4. CORRECTION DES ERREURS

a) Définition :
Le critère Correction des Erreurs concerne les moyens mis à la disposition des utilisateurs pour leur permettre de corriger leurs erreurs. Justification(s) : Les erreurs sont d’autant moins perturbatrices qu’elles sont faciles à corriger.

Exemples de recommandations :

• Fournir la possibilité de modifier les commandes lors de leur saisie.
• À la suite d’une erreur de saisie d’une commande ou de données, donner aux utilisateurs la possibilité de corriger seulement la portion de données ou de commande qui est erronée.
• Si les utilisateurs se rendent compte qu’ils ont commis une erreur d’entrée de données, leur donner la possibilité d’effectuer, au moment de leur détection d’erreur, les corrections souhaitées.

b) Commentaire(s) :
Correction des Erreurs vs Actions Minimales
Les problèmes liés au critère Actions Minimales peuvent résulter de mécanismes de correction des erreurs inadéquats. Lorsque le nombre d’actions nécessaires à la correction des erreurs peut être réduit, il s’agit d’un problème de Correction des Erreurs. Le critère Actions Minimales concerne donc les procédures autres que celles liées à la correction des erreurs.