Les messages d’erreur
En tant qu’UX writer, votre objectif est de créer le parcours idéal, celui au cours duquel les utilisateurs et utilisatrices comprennent les messages et réalisent les actions au bon moment.
Toutefois, il peut arriver que les choses ne fonctionnent pas comme prévu, ou certains·nes utilisateurs·trices peuvent suivre une autre voie que celle que vous avez imaginée.
Il existe plusieurs causes d’erreurs :
- Les erreurs systèmes, générées par un problème technique, dans le produit, lié au serveur ou à la connexion
- Des erreurs générées par les utilisateurs et utilisatrices, comme par exemple, un champ de formulaire incomplet ou contenant une donnée erronée
Les messages d’erreur peuvent prendre plusieurs formes :
- Une notification au sein de l’interface (toast, fenêtre pop-up…)
- Un nouvel écran ou une nouvelle page qui apparaît, dédié entièrement au message d’erreur (empty state)
- Un message dit inline ou dans le contexte de l’erreur — généralement utilisé pour les erreurs liées à l’utilisation du produit par l’utilisateur·trice
Exemple de message d’erreur contextualisé - PayFit
L’utilisateur·trice a inséré un numéro qui ne correspond pas au format attendu. Le message d’erreur lui indique simplement comment résoudre cela.
Exemple de message d’erreur avec une fenêtre pop-up - Spotify
Le message d’erreur technique est bref, mais clair. On pourrait recommander d’expliquer ce qu’il s’est passé, mais parfois il peut être difficile d’expliquer la cause d’une erreur technique.
Exemple de message d’erreur avec un empty state - Qonto
Lorsqu’une erreur technique a lieu sur l’application Qonto, dans certains cas, une nouvelle page apparaît. C’est le cas notamment quand l’application est en brève maintenance. L’équipe a choisi de rassurer les utilisateurs et utilisatrices.
C’est pourquoi il est essentiel de ne pas prendre à la légère ces erreurs, mais plutôt de concentrer une bonne partie de son énergie à concevoir des messages clairs, utiles et dotés d’une bonne dose d’empathie.
☝️ Trop de messages d’erreur tuent le message d’erreur.
Parfois, il vaut mieux désactiver un bouton pour signifier qu’une action de l’utilisateur·trice est attendue plutôt que de le ou la laisser faire des erreurs.
⛔️ Exemple d’un formulaire rempli de messages d’erreurs - Trusty
Bien qu’il soit peu probable qu’un utilisateur ou qu’une utilisatrice clique sur le bouton d’action sans avoir rempli l’ensemble des champs, tout ce rouge est assez angoissant, vous ne trouvez pas ? Comme le formulaire est assez conséquent, une piste serait de désactiver le bouton d’action primaire, jusqu’à ce qu’un certain nombre de champs soient remplis.
De plus, vous remarquerez que les messages d’erreur n’ont pas du tout été travaillés.
