L’UX writing est le parent pauvre du design. Et pourtant, il devient un différenciateur stratégique de plus en plus important — et un facteur clé de la résilience d’un produit.

Que celui qui n’a jamais rencontré (ou même rédigé) ce genre de message d’erreur jette la première pierre :

Juste un exemple parmi des milliers de choses qui ont apparemment « mal tourné » quelque part dans le monde.

« Et alors ? Où est le problème ? De toute façon, les utilisateurs ne lisent pas », pourraient rétorquer certains.

Eh bien.

Une part importante de nos interfaces est constituée de texte, et nous les concevons en partant du principe que les utilisateurs savent lire.

La moindre des choses serait de s’assurer que ce qu’ils lisent a réellement du sens.

Ici, le message n’est ni explicatif, ni factuel, ni même empathique. Il se contente de rejeter la responsabilité de la résolution du problème sur le client, au pire moment possible.

(Non pas qu’il y ait jamais de bon moment.)

Après ma première réaction — qui consistait, naturellement, à troller un peu et à baptiser ce type particulier de microcopie « une Britney » —, j’ai commencé à me demander :

Comment diable en sommes-nous arrivés là ?

Un benchmark bâclé ? Une volonté excessive de paraître branché ? Un mépris total de la langue en tant qu’interface ? Un cocktail bizarre de mythes cognitifs sur « les utilisateurs, ces créatures mystiques que tout le monde prétend comprendre » ?

Quelle que soit la réponse, quelque part dans le monde, au moment même où vous lisez cette phrase, quelqu’un a les yeux rivés sur ce message d’erreur exact après avoir perdu un client, une base de données ou quinze minutes de sa vie.

Tout cela parce que nous préférons écrire « Oups » plutôt que de prendre le temps de concevoir le contenu comme un élément fondamental de l’expérience utilisateur.

Pourquoi les messages d’erreur sont-ils (encore) conçus d’un point de vue purement technique ?

Les messages d’erreur trouvent leur origine dans l’ingénierie, pas dans le design d’expérience.

Ils sont écrits pour les développeurs.

Historiquement, un message d’erreur est un artefact technique : un voyant d’alerte qui s’allume lorsque quelque chose ne tourne pas rond dans le système.

Et comme le système ne peut plus délivrer ce que l’utilisateur est venu chercher, quelqu’un doit lui dire qu’une action est requise avant de pouvoir continuer.

Probablement quelque chose qu’il doit faire lui-même.

Même si, vous savez, cela pourrait aider de lui dire clairement quoi.

Les messages d’erreur ont été conçus pour diagnostiquer, pas pour rassurer. Pour journaliser, pas pour expliquer.

Alors, naturellement, nous avons fini par produire des messages qui ressemblent trait pour trait à des logs.

Et tant pis pour la personne de l’autre côté de l’écran.

Une personne qui pourrait être en train de :

• Paniquer.

• Perdre des heures de travail.

• Voir son flux de production s’arrêter net.

• Se demander si son activité ne va pas prendre un coup sérieux.

Entre l’intention du système (« J’ai planté ») et celle de l’humain (« Aidez-moi à comprendre ce qui se passe et comment m’en sortir »), il n’y a absolument aucun alignement.

Et ce décalage n’est pas nouveau.

C’est l’héritage d’une époque où le texte n’était pas considéré comme une interface, mais plutôt comme un dépotoir pour informations internes. Une époque où le texte servait principalement à enregistrer, consigner ou archiver.

Alors, on logue des événements.

Et ensuite, on se rassure sur la qualité de notre expérience utilisateur en ajoutant un petit mot enjoué :

« Oups ! »

Un mot qui ne remplit absolument aucune fonction logique ou émotionnelle, si ce n’est d’annoncer au monde que…

Eh bien, oui.

Quelque chose s’est cassé.

Sauf que plus personne n’est surpris quand un logiciel plante de nos jours.

Ce qui est surprenant (et épuisant), c’est que notre façon de communiquer à ce sujet n’a pas évolué depuis vingt ans.

D’accord. On s’est assez plaint. Qu’est-ce qu’on fait concrètement ?

Remettre un pilote dans l’avion ? (Désolé. Je n’ai pas pu résister. C’est un moment Britney.)

Nous commençons par nous soucier de nos utilisateurs et du parcours qu’ils traversent lorsque nous écrivons pour eux.

Aujourd’hui encore, étonnamment peu d’équipes se posent ces questions fondamentales :

Que perd l’utilisateur à ce moment précis ?

Quel est le ton juste pour l’accompagner dans cette épreuve ?
En vous basant d’abord sur ce qu’il ressent, et ensuite sur le positionnement de votre marque.

De quel niveau de détail a-t-il réellement besoin ?

Quelles informations factuelles puis-je fournir sans rien inventer ?
(Oui, s’il vous plaît. De grâce, arrêtez de prendre vos utilisateurs pour des idiots.)

Quelle action simple puis-je lui proposer sans faire peser la charge sur lui ?
Parce que vos utilisateurs vivent déjà dans un web « merdifié » où ils travaillent gratuitement pour votre SaaS, le SaaS de vos concurrents, les sites administratifs et toutes les plateformes imaginables.

Idéalement, nous ne devrions pas aggraver les choses.

Ou du moins, pas beaucoup plus.

En d’autres termes, nous devons prendre en compte :

La criticité du moment, l’état émotionnel de l’utilisateur, la nature de la panne et les besoins psychologiques et fonctionnels auxquels il faut répondre.

De messages d’erreur aléatoires à un véritable cadre d’UX writing

J’ai essayé de formaliser ces questions sous forme de matrice, inspirée d’une approche employée par une ancienne collègue de Leboncoin (qui est devenue par la suite UX writer).

Cartographiez vos messages.

Construisez vos matrices à l’aide de cartes d’empathie utilisateur.

Et observez la qualité de vos messages d’erreur s’améliorer.

En même temps que l’utilisabilité de votre produit.

Il convient de rappeler que la qualité des messages d’erreur est l’un des critères ergonomiques identifiés par Bastien et Scapin, même si d’autres cadres méthodologiques ont depuis redistribué les cartes.

Et, à un niveau bien plus pragmatique, adopter cette approche peut vous aider à :

• Réduire le churn.

• Diminuer les tickets de support.

• Améliorer les taux de finalisation des parcours.

• Renforcer la qualité perçue du produit.

Parce que si vous avez déjà conçu un produit qui « fonctionne », mais que certains moments critiques viennent toujours briser l’expérience…

C’est sans doute par là que vous devriez commencer à regarder.