Camille Promérat et Amandine Agić sont toutes les deux UX Writers et Content Designers. Dans cette contribution sans langue de bois, elles racontent l’envers du décor de leur métier… afin de sensibiliser les product managers. Très utile.

Après des mois de recherche, tu as enfin mis la main sur un·e UX writer – même si cette personne préfère peut-être l’intitulé content designer… Tu te dis que les wordings vont bientôt atteindre la consistence idéale (ou « cohérence idéale » si tu n’es pas adepte du franglais). Aleluia !

Sauf que les choses vont très probablement tourner différemment. Et que ta nouvelle recrue va te demander un point assez rapidement, en te parlant de choses que tu ne soupçonnes pas.

Afin d’éviter toute désillusion, voici donc 9 petits trucs à savoir pour bien travailler et… communiquer avec un·e UX writer !

Ces conseils sont aussi pertinents si tu es en train de chercher un·e UX writer pour ton équipe UX (pas pour ton équipe marketing, ni pour la brand, hein ?). Cela pourra te donner quelques billes en entretien d’embauche. Plutôt que de ne parler que de KPI contenu ou de sujets linguistiques que tu ne maîtrises pas forcément… Tu verras, tu enverras un très bon signal !

« De l’intitulé de poste UX Writer, on retient souvent Writer, l’écriture, et on imagine donc un dictionnaire de synonymes et un correcteur Word amélioré. » – Camille Promérat (à gauche) et Amadine Agić (à droite)

1. Écrire n’est pas traduire

Dit autrement : UX Writing et localisation ne sont pas synonymes. Ce n’est pas parce que notre livrable c’est “les wordings” que l’on peut gérer un processus aussi complexe que la localisation.

Petit rappel :

  • L’UX Writing, c’est le fait de concevoir via le contenu une expérience utilisateur claire et efficace.
  • La localisation, c’est le fait d’adapter le contenu d’une langue source vers une culture cible. Et quand on dit adapter, ce n’est pas passer des textes dans Google Translate… 

La localisation est intrinsèquement liée à la stratégie d’expansion d’une entreprise. Doit-on traduire son application pour pénétrer un nouveau marché ou garde-t-on la langue anglaise ? Est-il nécessaire de traduire aussi souvent une langue parlée par 2 % de nos utilisateurs qu’une parlée par 45 % ? Tout cela se décide avec le Chief Product Officer (CPO).

Notons quand même que, bien que différents, UX Writing et localisation sont deux facettes de la même pièce.

Une traduction ne pourra être bonne que si le contenu source a été pensé en amont. Et sans bon processus de localisation, on perdra l’impact et la cohérence générés par l’UX Writing.

2. L’importance de « ranger » le contenu

Avec des google sheets, on va pouvoir bricoler… mais on va surtout pouvoir s’arracher les cheveux !

Les TMS (Translation management system, qui va reconnaître les expressions déjà traduites et les réinjecter et alerter votre équipe de traduction quand un mot ne sera pas traduit par son équivalent officiel) ou CMS (Content management system) vous éviteront de perdre beaucoup de temps. De l’équipe UX à la QA, personne n’aime ces trop longues parties du jeu des 7 erreurs sur du japonais ou de l’arabe…

Tant qu’on y est, rappelons l’importance d’uniformiser ce processus. Afin de ne pas avoir une squad qui gère son contenu sous Figma, l’autre avec GSheet et une dernière avec Notion. Le contenu et ses traductions doivent être stockés à un seul et même endroit. Le jour où vous voudrez harmoniser tous vos CTA ou arrêter d’utiliser un mot (qu’une autre marque a déposé par exemple ou sur lequel le légal a un doute), vous nous remercierez de vous avoir parlé de Phrase, Smartling et de Transifex !

3. Sans glossaire, on n’avancera pas

Oui, avouons-le, un glossaire, ça fait peu rêver. La bonne nouvelle, c’est qu’on en connaît qui aiment ! Pense à un design system des mots : tu veux que tout le monde utilise le même mot pour parler de la même chose.

Le fichier JSON avec tous les textes de votre produit est peut-être prêt depuis longtemps. Et vous avez envoyé tout votre contenu produit à votre UX Writer dès son premier jour pour gérer la seule, l’unique, la legacy (pour les gens normaux : les textes existants). OK.

Mais, outre le fait que relire et réécrire des textes dans un JSON relève plus de la correction que de l’UX, quid des incohérences terminologiques ? Les paramètres sont-ils aussi appelés réglages ? Et quelle est la différence entre dashboard et overview ? Et ça, ce n’est qu’une des facettes du problème.

Oui, car le produit n’est pas tout seul. Il cohabite avec nombre d’autres départements : le marketing, le product marketing, la documentation, le service clientèle. Quand chacun·e choisit un terme différent pour parler de la même fonctionnalité ou change en cours de route… C’est le début de la cacophonie dans l’expérience.

C’est là que la création d’un glossaire peut vous sauver. Et surtout : choisissez une personne qui restera responsable de la mise à jour du fichier. Les universités françaises forment des linguistes, et ces personnes adorent ce genre de nerderies.

4. Le processus de validation,“cékikivalide”

Ah, le fameux gonogo 

Qui est responsable (owner, si tu y tiens) du contenu ? La validation vient-elle des PM ? Peut-on imaginer des instances de validation qui varient selon l’importance du sujet ? On a vu trop de pages un peu cachées débattues pendant des heures de réunion ou des pages dévalidées à l’arrache.

Pour ne pas vous alerter : commencez à aborder le sujet avant la prise de poste de la perle rare.

Valider, remettre en question

Pour éviter à ton UX writer d’interminables échanges, prépare un peu tes troupes et commence à affirmer que : 

  • Le contenu d’un produit n’est pas sujet à un commentaire de texte et les connotations supposées d’un mot en anglais ne doivent pas faire l’objet de longues réunions entre francophones plus ou moins fluent.
  • La longueur du texte n’est pas un indicateur de réussite. Vos messages d’erreur, en devenant accessibles et actionnables, vont probablement gagner un peu de corps. Certains CTA également. D’autres parties subiront un écrémage sévère. Mais l’UX writer n’est pas un extracteur de jus.
  • Il va falloir supprimer des informations. Votre produit est-il si puissant que vous ne pouvez pas le résumer en moins de 9 points ? Il va pourtant falloir.
  • Si une page est en ligne et qu’elle ne convertit pas autant qu’on le voulait, le problème n’est pas forcément le contenu, il faut probablement la revoir dans son ensemble. Tout comme on n’ajoute pas une fonctionnalité sans comprendre comment elle s’intègre à un produit existant, on ne “pond” pas des textes sans maîtriser contexte et objectifs.
  • “Je n’aime pas” n’est jamais un retour valable : on débat KPI, on fait des tests utilisateurs, on va chercher de la data etc. Si vous voulez en savoir plus, voici une bonne vidéo sur le sujet :
https://youtu.be/dkjIICx24fs

5. Le contenu fait partie du design system

Le design est une démarche qui ne se résume pas à la couleur des boutons et du choix de la typo, vous en avez conscience. Votre design system doit le refléter. Mike Winnington en parle mieux que nous :

https://youtu.be/gxOHqpn-hs4

6. Je ne peux pas tout faire, on peut m’aider ?

Il va falloir emporter toute l’équipe UX sur le sujet, parce que tant que le ratio de 1 UX writer pour 3 designers max ne sera pas atteint, il faudra sortir des pages sans intervention ou presque des UX writers.

  • Ça tombe bien, faire du bon contenu, c’est souvent plus facile qu’on ne le croit.
  • Plus c’est écrit de manière simple et naturelle, mieux c’est. Les fioritures, on enlève. Si vous avez fait le lycée en France, oubliez tout des dissertations.
  • Les guidelines vont aider les designers à créer des attentes pour un “minimum viable content”.

7. L’UX Writing, ce n’est pas que des mots

De l’intitulé de poste UX Writer, on retient souvent Writer, l’écriture, et on imagine donc un dictionnaire de synonymes et un correcteur Word amélioré.

Mais si vous avez réussi votre recrutement, c’est avant tout une personne qui résout des problèmes qui rejoindra votre équipe.

Essayez ça : invitez l’UX Writer au lancement d’une nouvelle fonctionnalité et écoutez ses questions. Designers, proposez-lui une session de réflexion sur les parcours, les contenus, la hiérarchie de l’information. Vous verrez, en quelques minutes (ou heures), vous ferez émerger de nouvelles problématiques et ne tomberez peut-être pas dans certains pièges liés à une conception trop rapide.

Verbatim d’une Product Director à l’appui :

“On a invité notre rédactrice à un brainstrom et en quelques instants elle nous a présenté le problème sous un angle complètement différent, et l’a solutionné de manière… simple. Ça a tout changé.”

Voilà c’est pas nous qui l’avons dit.

8. Il va falloir l’aider à prioriser les sujets

Vous allez le remarquer rapidement : l’UX Writer a la fâcheuse tendance à vouloir bien faire. Ce qui signifie dire oui à trop de sujets afin de se rendre utile et de montrer qu’il ou elle est là pour aider. En période d’essai, on a clairement du mal à dire non par peur de déplaire, de passer pour un tire-au-flanc et donc de se voir montrer la porte. 

Pourtant, quand on vient d’arriver, on ne connaît pas forcément bien les priorités de l’entreprise, qu’elles soient business ou produit, donc on ne sait pas si tel ou tel sujet est important. Et c’est normal. Il faudra donc lui présenter la stratégie de l’entreprise à court, moyen et long terme, ainsi que la roadmap produit. Parce que vos designers sont souvent répartis par tribe/pod/petite entité autonome, mais l’UX writer qui vient d’arriver non.

Qui dit temps pour appréhender le sujet dit forcément moins de temps pour produire, et, quand les équipes attendent l’UX Writer comme le messie depuis des mois, il faut l’expliquer. 

9. Il va falloir l’aider à trouver sa place

Les équipes UX produit qui recrutent en UX writing sont souvent en pleine structuration. Soit tout le monde trouve sa place en même temps… soit le product management va prendre l’ascendant. C’est donc de la responsabilité de son manager de le ou la placer au sein de la bonne équipe.

Ici, il s’agit du syndrome de la rentrée scolaire : c’est parfois difficile d’arriver dans une équipe où il y a déjà plusieurs PM et plusieurs designers.

En tant que manager, prenez le temps de préparer vos équipes à l’arrivée de cette nouvelle compétence et de définir son scope. N’oubliez pas les piqûres de rappel.

C’est bien beau de savoir où placer cette personne, mais il faut maintenant l’intégrer aux différents processus de l’entreprise. Travailler les textes d’une interface en fin de process n’a que peu d’intérêt, alors que nous pouvons vraiment avoir un impact faramineux sur les interfaces finales si nous arrivons avant qu’il soit trop tard.

Il est donc vraiment très important de documenter le processus de création design en incluant toutes les étapes auxquelles le ou la rédactrice va devoir participer. Sans oublier les livrables, les outils utilisés et les différentes étapes de validation. 

Bon courage !

Les autrices :

Camille Promérat (à gauche) et Amandine Agic sont UX Writers et Content Designers indépendantes et membres de UX Writers France.

Retrouvez tous nos articles sur l’UX Writing notamment :

Le Ticket 1