Concevoir l’erreur comme une expérience à part entière

Comprendre le contexte et la maturité du produit

Dans les missions courtes ou ponctuelles, où beaucoup de choses doivent être construites en peu de temps, le traitement des erreurs est souvent minimisé : peu de temps, peu de retours utilisateurs, priorité au parcours principal. Mais dans les missions longues ou lorsqu’un produit arrive à maturité, le traitement des erreurs devient un levier de qualité, de confiance et de différenciation. Nous distinguons 2 types d’erreurs :

• les erreurs prévisibles, également dites erreurs silencieuses, c’est-à-dire les erreurs qui peuvent être considérées comme « normales » (ex : un mot de passe invalide, une entité verrouillée, etc.) et qui ne nécessitent pas l’arrêt de l’exécution du programme.
• les erreurs imprévisibles, également dites erreurs graves (ex: la connexion à la base de données ne fonctionne pas, etc.). Il peut s’agir d’une erreur d’écriture sur le disque, d’une panne de réseau ou, plus généralement, de toute interruption inattendue.

 

4 grandes familles d’erreurs en UX

Les erreurs prévisibles se retrouvent souvent dans les erreurs de saisie, compréhension ou anticipées. Les erreurs imprévisibles sont majoritairement techniques ou critiques (Famille 400, 500).

Erreurs de saisie

Ce sont les erreurs les plus fréquentes. Elles concernent les champs mal remplis ou incomplets (email invalide, mot de passe trop court, champ oublié…).
Un exemple classique est l’affichage des contraintes avant la saisie du mot de passe. L’utilisateur peut ainsi choisir un mot de passe en connaissance de cause. La prise en compte des caractères renseignés avec le passage d’un état inactif à actif pour signifier que la contrainte est acceptée permet également de limiter les erreurs.

Au lieu d’écrire en rouge “Invalid input”, il est préférable de guider l’utilisateur avec ce type de message “Le mot de passe doit contenir au moins 8 caractères, dont une majuscule et un chiffre.” On pense aussi accessibilité en associant couleur et symbole. Pour rappel, l’information ne doit pas être donnée uniquement par la couleur (Critères 3.1)

©Hamza sur Dribbble

Erreurs de compréhension

Elles ne sont pas liées à la saisie mais à une mauvaise interprétation de l’interface. C’est par exemple le cas lorsque le libellé d’un bouton d’action est ambigu ou flou. Dans un parcours de plusieurs étapes, les boutons “Confirmer”, “Valider” ou “Continuer” sont à utiliser avec précision en fonction de l’étape en cours.

Au lieu d’écrire “Oui/Non” ou des libellés imprécis, il est préférable d’utiliser des verbes d’action qui décrit précisément l’action attendue.

©Blake Hunter sur Dribbble

Erreurs techniques

Ce sont les erreurs qu’on ne peut pas toujours éviter (erreurs imprévisibles), mais qu’on peut rendre compréhensibles. La fameuse 404 & co, erreur API, etc.. L’utilisateur n’a pas forcément la connaissance technique pour comprendre la cause. Le guidage et le vocabulaire utilisé sont essentiels pour proposer une alternative comme contacter le support, revenir à l’accueil, réessayer. Ne pas hésiter à travailler autour d’un système d’illustrations pour chaque cas.

Au lieu d’écrire “Error 503 – Server unavailable”, il est préférable d’expliquer la situation “Nous rencontrons un problème temporaire. Votre contenu est sauvegardé. Vous pouvez réessayer dans quelques instants.”

©Soffia sur Dribbble

Erreurs anticipées

Ce sont des erreurs évitées via une conception intelligente. C’est par exemple le cas avec la prédiction, les suggestions automatiques, le pré-remplissage de certains champs qui ont été collectés précédemment, l’apparition de fenêtres de confirmation pour des actions irréversibles, etc.. En automatisant certaines opérations, nous aidons l’utilisateur à se concentrer sur l’essentiel et à limiter le nombre d’erreurs possibles (réf. charge mentale de l’utilisateur). L’objectif est de protéger l’utilisateur de l’erreur, plutôt que de la traiter après coup.

© Mark Babatunde sur Dribbble

Identifier et documenter les erreurs : une démarche UX à part entière

Cartographier les “Unhappy paths”

Concevoir l’erreur comme une expérience à part entière, c’est anticiper les erreurs possibles. Pour les identifier, nous avons recours au “Error paths” ou “Unhappy path”, qui consiste à cartographier dans les parcours là où l’utilisateur bifurque, échoue, hésite ou abandonne. Ces retours peuvent provenir de l’expérience de l’équipe, des retours de tests utilisateurs ou d’autres retours collectés (client / support / analytics).

©Sarah Babetski sur Dribbble

Catégoriser les erreurs

Une fois identifiée, l’erreur est classée et catégorisée dans un fichier selon différents critères :

• la nature de l’erreur – Quel est le problème détecté ?
• le contexte de l’action – À quel moment du parcours l’utilisateur se trouve-t-il ?
• la gravité de l’erreur – L’utilisateur peut-il continuer ou l’action est-elle bloquée ?
• la fréquence de l’erreur – Est-ce une erreur ponctuelle ou récurrente ?
• la priorité ( utilisabilité versus développement) – Corriger cette erreur améliore-t-il significativement l’expérience par rapport à l’effort de développement nécessaire ?
• la solution – Comment l’erreur peut-elle être résolue (automatiquement ou par l’utilisateur) ?

 

Exemple donné par Yuna Orsini dans son article Retour d’expérience sur la révision en profondeur de notre système d’erreurs.

Formuler un message d’erreur optimal

Indépendamment de l’erreur, il est essentiel de structurer le texte explicatif avec une structure cohérente et logique : Ce qui ne va pas → Pourquoi → Comment le résoudre

Exemple donné par Jenni Nadler dans son article When life gives you lemons, write better error messages.

Voici l’exemple d’un exemple d’un message d’erreur inadapté. Il utilise un ton inapproprié, rejette la faute sur l’utilisateur, emploie un jargon technique et reste trop vague.

Exemple donné par Jenni Nadler dans son article When life gives you lemons, write better error messages.

Voici l’exemple d’un message d’erreur adapté. Il explique ce qui s’est passé et pourquoi, rassure l’utilisateur, fait preuve d’empathie, l’aide à résoudre le problème et lui offre une solution ou une alternative.

Pour rappel, la gestion des erreurs fait partie des 8 critères ergonomiques de Bastien & Scapin. Il se compose de trois sous critères qui sont la protection contre les erreurs, la qualité des messages d’erreurs et la correction des erreurs.

De plus, le langage doit être clair, humain, non culpabilisant et refléter le ton du service (pas d’humour excessif, ni de jargon technique). De plus, il est important d’adopter un ton approprié à la gravité de l’erreur pour permettre d’éviter d’aggraver une mauvaise expérience.

Modalités d’affichage des erreurs

Toutes les erreurs ne se valent pas et leur mode d’affichage non plus. Le choix entre un message discret, une bannière, un toast, une modale ou une page dédiée n’est pas esthétique, mais fonctionnel et émotionnel.

Message inline – Informer sans interrompre

Le message inline permet d’afficher un message d’aide, un statut ou un feedback, sans interrompre l’utilisateur dans son action. Placez le message au plus près de l’élément concerné et formulez-le avec un langage fonctionnel. Il est très fréquent dans les formulaires.

©Olena Iva sur Dribbble

Bannière – Erreur impactant qui nécessite une action de l’utilisateur

Une bannière affiche un message important et concis et fournit des actions permettant à l’utilisateur d’y répondre. Elle reste affichée jusqu’à ce qu’elle soit fermée par l’utilisateur ou si l’état ayant provoqué leur affichage est résolu.
Les bannières doivent être affichées en haut de l’écran, sous la barre d’application supérieure. Elles sont persistantes et non modales. Une seule bannière doit être affichée à la fois.

©Patryk Ilnicki sur Dribbble

Boîte de dialogue – Demande d’attention immédiate

La modale de dialogue bloque l’utilisation de l’application jusqu’à ce que l’utilisateur effectue une action ou quitte le dialogue (si possible). Il nécessite de faire prendre une décision à l’utilisateur à travers des choix explicites et éclairés. Ainsi, nous éviterons d’utiliser les modales pour des erreurs techniques non actionnables.

©Muhammad Bayu Pratama sur Dribbble

Page dédiée – Quand tout s’arrête

Page 404, page 500, maintenance, etc. Une erreur critique du système bloque l’utilisateur sur une pleine page. Comme expliqué plus haut, il est important de réorienter l’utilisateur vers une autre page, de lui donner une alternative ou l’informer d’un état temporaire.

Page 404 chez Yumans.design

Pour résumer

 

Rôle du Design System dans la gestion des erreurs

Une fois les erreurs correctement catégorisées et associées à un composant, il devient essentiel de les documenter. C’est ici que le Design System joue un rôle clé : il centralise les modèles de messages, les règles de ton, les comportements d’affichage et les spécifications visuelles. Cela garantit que toutes les équipes (produit, design et tech) appliquent les erreurs de manière cohérente, accessible et reproductible à l’échelle du produit.

 

Conclusion

Ce qui dégrade la confiance d’un utilisateur, ce n’est pas l’erreur. C’est le blocage, le manque d’explication ou le sentiment d’être abandonné par le produit au moment où il en a le plus besoin. L’erreur doit devenir un moment de guidage. Quand elle est bien traitée, elle renforce l’expérience, la confiance, la crédibilité et même la fidélité.

L’erreur ne doit pas être une parenthèse dans l’expérience. Elle en fait partie.

En fin de mission, nous remettons à nos clients un UI Kit et des maquettes avec des cas d’erreurs prévisibles et imprévisibles. Mais soyons honnêtes : pour aller plus loin, ce sujet demande un vrai travail collectif. Développeurs, UX et UI designers, product managers, data scientists, UX writers, etc. tout le monde est concerné.
Comme le dit Avishai Abrahami, CEO de Wix : « Les erreurs sont le résultat d’un mauvais développement et d’un mauvais produit. Nous devons tous nous en préoccuper ensemble. »