Construire un Content system

#33 Interview de Kassandra Delibie, Content designer chez Criteo

mars 13, 2023

Bien le bonjour 👋

Quoi de mieux qu’une bonne newsletter (et un bon soleil ☀️) pour commencer la semaine ? Je suis de retour avec un sujet encore trop peu abordé sur UX Content Craft, mais qui prend progressivement de l’ampleur dans le monde de l’UX writing. Je laisse aujourd’hui la parole à Kassandra, qui nous partage sa méthodologie pour bâtir un Content system (et le diffuser à toute l’équipe pour qu’il soit utilisé bien sûr).

Au sommaire de cette nouvelle édition :
Construire un Content system - Interview de Kassandra Delibie, Content designer chez Criteo
Mon bébé que je ne suis pas peu fière de vous présenter : Lorem
Les prochains événements francophones autour du Content design
Tour d’horizon des jobs d’UX writer

Bonne lecture 📄

Cette newsletter vous est envoyée gratuitement à vous et à 428 autres personnes. Si vous l’appréciez, n’hésitez pas à la partager, à la soutenir financièrement sur Tipeee, ou même à me proposer des sujets ou invité·es.

🎙️ Construire un Content system

Interview de Kassandra Delibie, Content designer chez Criteo

Kassandra est officiellement UX writer depuis plus de 3 ans. Elle précise “officiellement”, car, comme beaucoup d’UX writers, elle faisait de l’UX writing de façon parcellaire dans son boulot de gestionnaire de projets digitaux/product designer, sans vraiment savoir qu’il existe un nom pour ce métier.

Après 3 ans dans cette entreprise et plusieurs rencontres (dont Pauline Thomas et Camille Promérat), elle se lance en UX writing, en freelance.

Pourquoi devenir UX writer ? 1. L’écriture, ça a toujours été sa passion. 2. Ça a été une grande source de frustration en tant que product designer : trop de débats, difficile de trouver le consensus, pas de guidelines, les contenus se faisaient plutôt sur un coin de table.

En juin 2021, Kassandra rejoint Criteo. En freelance, seule, elle avait l’impression de tourner en rond et de partir trop tôt : elle créait des tons de voix, des guidelines, elle formait les designers, et sa mission se finissait. Ne pas pouvoir rester plus longtemps pour participer et voir émerger les projets était donc une seconde frustration.
Elle avait aussi envie de gagner en expertise aux côtés de personnes elles-même expertes de leur métier.

Pile au moment de ses questionnements, la head of design et la lead UX de Criteo la contactent. Elle commence en freelance, mais le fit est tellement parfait qu’elle rejoint pleinement l’entreprise. L’ambition de l’équipe design était alors de grandir et de devenir plus experte, et un budget était disponible pour l’embauche d’un·e UX writer. De belles opportunités et de nombreux challenges s’ouvraient à Kassandra.

Les planètes s’alignaient.

Avant de rentrer dans le vif du sujet, posons quelques bases : comment est constituée l’équipe design et UX writing chez Criteo ?

Dans notre équipe “coeur”, en plus de la head of design et la lead UX, il y a une dizaine d’UX designers répartis sur des parties de produit ou des fonctionnalités. Il y a également 3 UI designers, qui réalisent notamment les maquettes et maintiennent le design system. Quant à l’UX writing, pour le moment, l’équipe se résume à moi-même (rires).
Notre antenne à New-York compte une UX writer, mais nous avons des périmètres, des rôles et des méthodes complètement différents.

Il y aussi une vingtaine d’autres designers éclatés sur d’autres produits de Criteo et d’autres marchés, que l’on souhaite faire converger progressivement.

Parmi tes missions, tu as commencé à concevoir le content system. Quel était le besoin initialement ?

J’ai rapidement mis le sujet sur la table, parce que je suis un peu obsédée par le système et l’organisation (rires).
Aussi, au bout d’un certain temps à apprendre à connaître le produit et à travailler dessus, je commençais à tomber sur les mêmes modèles (patterns). Inutile donc de réinventer la roue chaque fois. Il fallait fondamentaliser l’ensemble.

Quand on est la seule personne dont le métier c’est d’écrire, on peut se dire que c’est facile de le faire, c’est ton style, c’est ta patte et tu sais comment écrire les choses. Mais en UX writing, ce ne peut pas être le cas, surtout quand il y a plusieurs produits et que plusieurs designers, et même des product managers ou des développeurs, conçoivent les expériences. Ça en devient rapidement chaotique d’un point de vue cohérence et cela prend énormément de temps de concevoir les contenus. Si on n’a pas un référentiel, on n’y arrive pas.

Tu parlais de guidelines, que tu concevais lors de tes missions freelances. Quelle est la différence entre guidelines et content system ?

Les guidelines sont des grands principes d’écriture, qui sont plutôt statiques.
D’un côté, il y a ceux qui permettent d’exprimer concrètement la voix. D’un autre côté, il y a ceux conçus pour chaque tonalité. Même si certains peuvent être communs à plusieurs tonalités.
Pour concevoir ces principes d’écriture des tonalités, je m’inspire beaucoup de ce que propose Torrey Podmajersky dans son livre Strategic Writing for UX : le voice chart. Je l’ai adapté en tableau. J’y ai écrit les principes par tonalité : la façon de s’exprimer, la grammaire, le champ lexical, les temps, etc.

À la différence, le content system permet d’incarner et de décliner les principes d’écriture (ou guidelines) dans les fonctionnalités du produit, dans les composants du design system. C’est un vrai système : identifier des patterns de contenus et les distiller dans le produit. Ces patterns de contenus sont itératifs et testables.

Je reviens sur ton discours sur les tonalités. Et je vais complètement dans ton sens : les tonalités sont bien plus importantes que la voix.

Atlassian en parle très bien dans son design system. La voix, c’est notre personnalité. Le ton, c’est notre humeur. C’est totalement ça : en fonction des moments, le ton change. Tu ne peux pas toujours être drôle, ou rassurant, ou sérieux, etc. Tu augmentes ou tu baisses le volume de ta voix. Tu restes toi-même, mais tu t'adaptes à la situation, au moment, à l’information donnée ou l’action à demander à l’utilisateur·trice.

À l’heure où l’on parle, où en es-tu de la construction du content system ?

Avant d’arriver chez Criteo, Camille Promérat avait déjà fait un boulot formidable. Elle avait conçu la voix, elle avait commencé à travailler sur les différentes tonalités et un ensemble de guidelines.
Mon objectif était donc d’aller encore plus loin, pour avoir une cohérence dans les produits de Criteo, d’autant plus qu’ils sont traduits dans plus de 10 langues.

1️⃣ Avec ma collègue américaine, nous avons d’abord travaillé sur certaines règles d’écriture en anglais plus précises, en déterminant par exemple si nous utilisions l’anglais américain ou britannique (la capitalisation, l’utilisation de “s” ou de “z”, et “o” ou “ou” dans les mots, etc.). Tout en excluant pas mal d’éléments qui faisaient trop américains ou trop européens. L’idée étant de parler un anglais compris par les équipes (et les utilisateurs·trices) et non pas d’utiliser un anglais natif (qui finalement n’est plus très répandu).

2️⃣ Nous avons aussi travaillé sur des règles d’internationalisation. On s’assure d’une part que le contenu soit utile et clair pour l’utilisateur·trice mais aussi qu’il soit facile à traduire, à adapter sur les autres marchés.

3️⃣ Ensuite, avec un UX writer freelance, Zayd Mawas, on a mis en place le côté plutôt content system.
On a notre voix, on a nos guidelines d’écriture, mais maintenant comment peut-on vraiment systématiser quelque chose que l’on fait au quotidien ?

Vous êtes donc entré progressivement dans le processus de conception du content system. Concrètement, comment le concevez-vous ?

D’abord, on a identifié 7 types de conversations que l’on a avec les utilisateurs et utilisatrices sur toute l’interface.

On leur donne des bonnes nouvelles
On leur donne des mauvaises nouvelles
On leur parle de sécurité ou de données sensibles
On les aide et les guide
On leur dit qu’il y a un problème
On souhaite les engager
On leur annonce quelque chose

Pour chacune de ces conversations, on a retrouvé plusieurs exemples de contenus dans l’interface.

On a ensuite travaillé sur l’émotion des utilisateurs et utilisatrices dans chacune de ces conversations. Par exemple, quand on donne une mauvaise nouvelle, l’utilisateur peut être frustré.
L’idée était donc d’ajuster la tonalité de chaque conversation. Est-ce que la voix, dans sa forme brute, répond au besoin émotionnel ? Ou est-ce qu’il faut la changer légèrement ?

On a alors abouti à 3 variations de ton, et aussi 3 tonalités à part destinées à des moments très particuliers. On a donc 6 variations en fonction des types de conversations.

Aujourd’hui, on finit d’écrire les guidelines pour chacune de ces fonctionnalités. En se posant toujours les questions suivantes : quels sont les buts ? Qu’est-ce qu’on cherche à faire ? Comment présenter l’information ? Etc. C’est un travail de fourmi pour documenter des micro-décisions.

Avec les UI designers, on a créé des ateliers autour d’échelles émotionnelles, c’est-à-dire une échelle graduée d’émotions par conversation. Par exemple, pour annoncer une bonne nouvelle, l’échelle peut aller du “on s’y attend” jusqu’à quelque chose d’exceptionnel.
L’idée était de définir les composants du design system qui correspondent à ces aspects émotionnels. On range en quelque sorte les composants sur ces échelles émotionnelles. Telle variante de tel composant, on va la mettre ici ou là sur l’échelle. Bien sûr, un composant peut être utilisé pour plusieurs émotions, et plusieurs conversations.

L’idée aussi, avec ces ateliers, est de sensibiliser les designers et de “retourner la vapeur” : quand vous concevez, n’allez pas chercher tel composant tout de suite, réfléchissez à ce que vous voulez dire aux utilisateurs·trices (quelle est la conversation) et donc quelle est la panoplie de composants qui peuvent fonctionner pour faire passer le message.

On n’en est pas encore là, mais l’objectif final est d’avoir des sortes de templates de contenus directement dans les composants du design system.

Peux-tu donner un exemple concret ?

On a par exemple un composant d’information. Il est utilisé quand il ne se passe rien de particulier, il s’agit d’une information basique, c’est très neutre. Finalement, on s’est rendu compte que ce composant pouvait aussi faire l’affaire pour une alerte de très faible intensité. Par exemple : “Dans 2 mois, ton moyen de paiement va arriver à expiration.” Pour le moment, il n’y a pas d’urgence, mais c’est quand même important d’alerter l’utilisateur·trice là-dessus.

Bien sûr, le même composant peut être utilisé dans des conversations différentes.
En construisant le content system, on offre donc d’autres portées d’entrée pour l’utilisation des composants.

Le design system regroupe des composants qui sont assez fixes (même si un design system est amené à évoluer en fonction de l’évolution des pratiques et d’un produit). A contrario, dans un content system, tu ne peux pas écrire des textes qu’il te suffira de réutiliser dans le produit par la suite. C’est ça toute la complexité d’un content system.

Oui, je suis d’accord. Il y a des moments où tu peux reproduire certains contenus. Par exemple : pour un empty state (écran ou partie d’écran vide) où il n’y a pas de données, tu peux réutiliser le même type de contenu.
Tout l’enjeu d’un content system, c’est d’offrir la possibilité de création tout en guidant.

J’ai une image assez parlante en tête, qui m’a marquée quand j’étais au lycée : en poésie, on étudiait la structure des alexandrins. Comment faire pour écrire ce genre de poème alors que c’est tellement restrictif ? Mon prof de français, à l’époque, m’avait dit : c’est dans la restriction que vient la créativité. J’ai adoré cette vision.
L’esprit humain est fait de telle sorte que si tu ne lui donnes pas de limites, il ne sait pas où aller. Si tu lui donnes un cadre, il va aller se cogner contre ces barrières, et c’est là où c’est intéressant, c’est là où la créativité se révèle.

Le content system a pour objectif de cadrer la pratique tout en laissant la possibilité d’exprimer sa créativité.

De mon côté, il y avait aussi l’enjeu de systématiser mon job pour aller plus vite. Que je ne passe pas trop de temps à chercher une structure de phrase alors qu’il y a déjà des patterns qui existent. Si cela marche bien, dans un certain type de conversation, que les utilisateurs et utilisatrices sont habituées à cette structure, autant me et leur faciliter le travail.

Dans pas mal de guidelines ou de content system, on retrouve des do’s and don’ts. Que penses-tu de cette approche ? De mon côté, je trouve que l’intention est bonne, mais cela peut vraiment restreindre les équipes lors de la création de contenus. Il n’y a rien qui soit blanc ou noir. Les contenus jouent sur la nuance.

J’utilise des do’s and don’ts pour des guidelines fixes, comme la capitalisation, la ponctuation, les espaces, etc.
Mais je suis d’accord avec toi pour le reste. Il n’y a pas de bonne ou mauvaise réponse. Les tonalités, par exemple, sont des tendances. Je vais plutôt écrire “évitez/privilégiez ce champ lexical”.

Mais ce que je vois quand je donne des formations notamment (ndlr, au Laptop), c’est qu’on est formaté, pour un exercice, à avoir des réponses. Certains de mes élèves sont déstabilisé·es parce que je ne leur donne pas les corrigés. Je leur donne des orientations sur ce qu’ils ou elles peuvent améliorer.

Si on respecte les grandes guidelines et les règles de lisibilité, le contenu est clair, le principal est là.
Mais maintenant, il faut le tester. Il n’y a que comme ça que l’on peut savoir si le contenu est bon. Il n’y a que les utilisateurs et utilisatrices qui peuvent le dire (pas ton collègue, pas ton boss).

Tout à fait d’accord. Dans notre métier, il faut éviter de faire revoir le contenu par plusieurs personnes encore et encore. Car, au-delà des règles d’écriture, chaque personne a son opinion, et un contenu peut être écrit différemment selon les personnes. Tout le monde aura toujours une opinion différente.

Cela me fait penser… Dans son livre Leading Content Design, que j’ai adoré, Rachel McConnell donne un template de feedback. On y retrouve les catégories autour desquelles vous pouvez donner un feedback :

Ce n’est pas correct (c’est faux)
Ce n’est pas en rapport avec la marque
Il y a un problème légal
Il y a un problème d’utilisabilité
Ce n’est pas cohérent avec ce que l’on a pu dire jusqu’à présent

Ce sont les seules raisons pour lesquelles vous pouvez avoir un retour sur vos contenus.

Je trouve ça un peu violent (rires), mais en même temps, c’est très vrai.
Si tout est coché, et si finalement tu n’aimes pas ce que j’ai conçu, c’est ton problème.
Mais dans la réalité, c’est tout de même une discussion qui est dure à avoir.

Je vais bien noter ces raisons pour les ressortir si besoin ! (rires)
Tu parlais de tester les éléments du content system. Que veux-tu dire par là ?

Avec l’UX researcher, on commence à mettre en place des tests purement liés au contenu.
Jusqu’à présent, dans les tests d’utilisabilité organisés par les designers, je mettais mon grain de sel, je leur demandais de faire tester certains éléments de contenu pour m’assurer de leur compréhension.

L’idée est donc de fondamentaliser les tests de contenus. Pour ainsi avoir des données sur la tonalité qu’on a employé, l’utilité et la clarté des contenus, et ainsi valider ou invalider le pattern. Si ce n’est pas compris par l’utilisateur ou l’utilisatrice, on peut se poser les questions suivantes : ce n’est peut-être pas le bon ton ou pas le bon composant.

Si tu ne testes pas, ça reste juste de simples guidelines. Tester permet de faire évoluer le content system tout comme le design system, pour être le plus pertinent possible pour les utilisateurs et utilisatrices.

Après ce travail de conception, comment diffuser et faire en sorte que le content system soit intégré dans les pratiques ?

Le faire pendant la conception. À chaque fois que l’on mène un travail lié à la conception du content system, j’inclus les UX & UI designers et l’UX researcher autant que possible. Dans les ateliers, on se demande toujours : comment est-ce qu’on propose l’information aux utilisateurs·trices ? Par quels modèles passe-t-on ? Est-ce qu’il y a des trous dans la raquette à l’heure actuelle ? Est-ce qu’on utilise certains composants et certains patterns dans certains types de conversations alors que ce ne sont pas les plus pertinents ?

Ces questions nourrissent mon travail pour le content system d’une part, et d’autre part ça sensibilise les designers.

C’est un travail collaboratif. C’est long, c’est fastidieux, mais tu ne peux pas le faire seul·e. Tu le fais pour la conception, en intégrant ton travail directement dans les outils de conception. Alors tu ne peux pas travailler sur le content system sans les designers.

Construire ensemble, c’est déjà une bonne première étape pour assimiler et appliquer.

En plus des équipes design, est-ce que le content system va profiter à d’autres équipes ?

J’adorerais ! Mais pour le moment, mon travail se limite exclusivement au produit, c’est-à-dire à l’interface.
Le content system, tel que je le conçois, est très design oriented. Mais j’espère pouvoir y intégrer des conversations types sur Intercom ou des articles du centre d’aide par exemple. Parce que ça fait complètement partie de l’expérience.

Quels sont tes conseils pour concevoir un content system clair, utile à tous et à toutes, et qui permette d’assurer la cohérence dans le produit ?

Je dirais d’abord que, comme tout travail de design, vous ne pouvez pas concevoir le content system sans les utilisateurs·trices. Et là, vos premiers utilisateurs et utilisatrices, ce sont les designers.
Vous n’êtes pas obligé·e de mettre tout le monde dans la boucle, car cela peut devenir infernal. Mais faites des exercices avec les UI designers, faites-en d’autres avec les UX. Et intégrez les conclusions dans le content system.

La deuxième chose, c’est d’aller sur le terrain et fondamentaliser (oui, c’est le terme n°1 de cet échange) ce que vous pouvez recueillir dans les entretiens utilisateurs.
Bâtissez les tonalités d’après des tendances naturelles que vous avez perçu lors des entretiens ou dans des verbatims.

Et dernière chose : intégrez le content system dans les outils des designers pour favoriser son utilisation. Si le design system est dans Figma, élaborez le content system au même endroit. Si c’est sur Zeroheight, faites-le dessus.

Les ressources incontournables de Kassandra

Strategic Writing for UX, de Torrey Podmajerski (la bible de Kassandra pour élaborer la voix et les tons)
Content Everywhere - Strategy and Structure for Future-Ready Content, de Sara Wachter-Boettcher
Conversational Design, d’Erika Hall
Leading Content Design, de Rachel McConnell
Designing for emotions, d’Aaron Walter (pour savoir comment engager les utilisateurs·trices)

Aussi, allez fouiller dans les design systems des autres entreprises, tel que celui d’Atlassian.

Bien sûr, toutes ces ressources ont déjà rejoint le centre de ressources pour progresser en Content design 😉

📅 Les prochains événements autour du Content design

Book Club / Wake Up America, de John Lewis et Andrew Aydin - par Content Design FR
Mardi 21 mars, de 18h à 19h45 (heure française)
La formation à l’UX writing avec Lorem : quoi, comment ? - par… moi-même & Clara Perrot 🙈
Nous vous dévoilerons le programme de notre première formation en ligne à l’UX writing (je vous parle de Lorem un peu plus bas)
Mercredi 5 avril, 18h30 (heure française)

🔍 Ça recrute !

Qonto est à la recherche d’UX writers seniors pour son marché Allemand
Yassir cherche toujours toujours sa perle UX writer (Berlin ou remote)
Vous entamez une transition vers le Content design ? Et si vous faisiez un stage chez The Fork ?
Le groupe AVIV recrute un·e UX writer en Allemagne (si jamais vous voulez bouger)
So Digital Paris recherche un·e UX writer freelance, bilingue Français/Anglais pour un gros client (mi-temps sur un an) - Contactez Lola Regaldi
Maison de luxe cherche UX writer confirmé·e freelance pour une mission à Paris de 3 mois minimum

🚀 Envie de vous former à l’UX writing ?

Si vous me suivez sur LinkedIn, vous avez peut-être vu passer l’info… Après plusieurs mois de gestation, la grossesse arrive à son terme : je lance Lorem, avec ma partner in crime, Clara Perrot !

Keskecé ?

Que vous ayez envie de vous reconvertir au métier ou de gagner en expertise, on vous accompagne pour monter en compétences en UX writing.
Coaching individuel, coaching en entreprise et formation en ligne, il y en a pour tous les niveaux, pour tous les besoins et pour tous les budgets.

Nous avons annoncé la création de Lorem il y a un mois.

Dès la semaine prochaine, vous pourrez réserver un coaching, individuel ou entreprise
Fin avril, on sort notre toute première formation en ligne pour acquérir les bases de l’UX writing.
À cette occasion, si la formation vous intéresse, on répond à toutes vos questions (objectifs, programme, pédagogie, prix, format…) lors d’un live le 5 avril.

Bien sûr, si vous avez des questions, n’hésitez pas à me les poser par retour d’e-mail 😊