L'article décrit les différentes étapes qui ont mené à la création de l'équipe de conception de contenu au sein du gouvernement britannique. Il montre comment cette équipe a joué un rôle essentiel dans l'amélioration de l'expérience des citoyens sur les sites web gouvernementaux, en mettant l'accent sur la clarté, la concision et l'accessibilité du contenu. Cet historique illustre l'importance croissante accordée à la conception de contenu dans la transformation numérique du secteur public. merci Gladys pour le partage. https://contentdesign.london/blog/history-of-content-design-in-the-uk-government
Vous n'avez pas pu visionner notre événement sur les Content Systems en live ? Le replay est en ligne ! --> https://www.youtube.com/watch?v=wp3atowLBuAVous découvrirez : les bases du Content System les premier pas chez Bouygues Telecom et Mirakl un aperçu concret de leurs Content Systems Une discussion franche sur les challenges Un très grand merci à NEXTON de nous avoir accueilli pour cette table ronde dont on a tant parlé chez UX Writers FR.
Lorsqu'on utilise un produit numérique, on vient pour le contenu. On le consulte, on le crée, on le manipule. On ne vient pas pour les aspects purement visuels ou techniques. Le contenu est donc l'élément premier de votre produit. On peut catégoriser ce contenu en deux groupes : les contenus cœur ou métier. Ca peut être du texte, des images, du son, des vidéos, des graphes, des données, des PDF, et les mails aussi (ne pas oublier). les contenus liés à l’interaction et la navigation (boutons, menus, …), appelés aussi microcopy.
Nathalie Rosenberg
· Lead UX designer
· il y a 1 an
Je tombe souvent sur des interfaces qui comportent des éléments en français et en anglais. C'est un signe d'un laisser-aller. Si vous estimez que c'est anodin, n'oubliez pas que tout le monde n'est pas bilingue. Certains utilisateurs vont certainement être perdus. Ex : cette page de commande en français, mais pour une raison inconnue, le bouton de validation du panier est en anglais.
Nathalie Rosenberg
· Lead UX designer
· il y a 1 an
Hello à tous, petite question pour avoir vos rex (content et data?) sur une question épineuse. Quels éléments prendre en compte pour décider de prioriser entre un segment hyper mature mais plus petit en taille de marché (et potentiellement déjà servi par un produit concurrent) vs un autre débutant mais bien plus gros en potentiel marché (et sans aucun produit déjà acheté) ? J'ai un client dans le domaine de la cybersécurité x crypto et il s'avère qu'il y a deux grand types de clients: Les investisseurs expérimentés et / ou ayant un background technique qui pensent bien comprendre la technologie (des gaps observés), sont rapides à l'achat et capables de faire leur recherche. Les investisseurs lambda (retail investors) qui ne connaissent pas la technologie, ne connaissent pas les risques, et ont une grosse courbe d'apprentissage. Evidemment, pour le moment l'équipe en interne à essayée de faire un mix des deux approches et cela fait que notre segment moins expérimentés ne comprends pas vraiment le produit et ils ont crées des pages produits qui font des Km de long où la proposition de valeur oscille entre simple et technique. Je suis arrivé il y 2 semaines et en interne la discussion actuelle est soit de : Créer une section x page beginners (gros doute dessus) Simplifier le discours (au risque de repousser notre clientèle type - les plus expérimentés. Dans les tests, les éléments de discours trop simpliste ou marketeux réduit leurs perception de sérieux de la marque) C'est encore très frais dans ma tête mais de là où je suis j'ai 2 approches possibles en tête : Focus sur les clients sérieux car ce sont nos clients actuels , avec un cycle de vente court et la taille du marché actuel à conquérir serait déjà suffisant pour la boite en question. Option 2: Trouver les éléments de languages et besoins similaires entre les deux segments pour les mettre en valeur above the fold sur chaque pages clés. Puis ensuite proposer un discours plus technique en approfondissant. Évidemment ce sont des pistes pour l'instant mais heureux d'être challengés ! Merci
Ce n'est pas possible de refuser complètement. Surtout que si on est complètement lucide, si tu es en CDI et qu'on te demande de faire ça au début de ton contrat et que tu refuses, tu mets un peu ta période d'essai en jeu. Il faut peut-être poser deux ou trois jalons et après dire "non, ce sujet-là, on l'a déjà couvert, on va arrêter de revenir en boucle là-dessus et puis on va avancer". J'ai l'impression que c'est un piège dans lequel on est... Que ce soit les designers, les researchers et les UX writers. Les deux dernières catégories étant un peu plus dans ces problématiques là, mais en fait typiquement les devs, on ne leur demande jamais de prouver à quoi sert le code.
Il commence à y avoir en France des équipes contenu. C’est très positif, mais comment ça se passe ? Je pense qu'il y a plusieurs façons d'aborder la chose. D'une part, je pense qu'il faut être patiente. Évidemment il faut faire avancer les choses, mais dans l'écosystème de la tech en France, tu arrives dans des équipes qui n'ont aucune connaissance ou alors très superficielle des problématiques du contenu et de l'internationalisation. Donc il va falloir poser des jalons progressivement, mais tu ne peux pas arriver directement et avoir des exigences hyper élevées. Après, il y a des fois où je pense que la chose la plus importante, c'est d'apprendre à dire "non". Être capable de dire "Je ne veux pas travailler sur tous les projets en même temps, toute seule, et arriver en bout de course et faire de la relecture". Refuser de rendre une version appauvrie de ce qu'on aurait pu faire. Toi, tu sais que la version est appauvrie, mais du côté PM et de toutes les autres personnes, ils voient déjà une grosse amélioration dans ce que tu as fait. Si tu acceptes facilement de travailler comme ça, il n'y a pas vraiment de raison que ça change. Au début, il faut que tu fasses tes preuves en acceptant des projets qui ne sont pas gérés de manière optimale et en même temps, à un moment donné, il faut passer à une intégration en amont dans le cycle design.. Et cette bascule-là n'est pas évidente à faire, en fait, et elle est presque plus facile à faire s'il y a des projets sur lesquels tu n'arrives pas complètement à éviter la catastrophe. Parce que si tu passes ton temps à mettre des rustines sur des pneus complètement crevés, on ne va jamais changer de pneus !
Les langues et cultures étrangères ne vont pas s’adapter à votre produit. Une chose qui ne va pas fonctionner, c'est de laisser des personnes natives d'une langue, traduire l'interface simplement parce qu'elles sont internes. La traduction c'est un métier.Souvent, les personnes qui travaillent dans des start ups ou des grands groupes ont une appétence vers l'international, elles utilisent énormément d'anglicismes et vont les garder dans la copie finale alors que le reste du pays ne s'exprimera pas forcément comme ça.Déjà pour la génération de tes parents, la langue qu'on parle en interne dans une équipe startup, c’est pas clair… et potentiellement, ces personnes-là, selon le projet, ça peut être ta clientèle. Donc c'est un vrai sujet d'aller trouver des personnes professionnelles et ensuite, autant que possible, d'identifier soit une agence, soit des freelances, mais en tout cas d'avoir des points de contact fixes, de ne pas varier en permanence les personnes qui traduisent, c'est assez crucial. Ensuite, essayer de ne pas tirer les prix vers le bas parce que tu vas trouver des agences peu scrupuleuses qui paient très mal leurs équipes. Si tu as une petite connaissance des métiers de la traduction, tu te rends compte que ça ne peut pas marcher. Les pros facturent au mot et ont intérêt à traduire le plus vite possible. Si tu lui envoies des docs pour un petit projet, peu prendront le temps de lire pour passer à un autre projet. Donc si tu as vraiment besoin de briefer, tu paies à l'heure et tu fais une réunion pour expliquer le projet. Soit tu prends des freelances avec qui tu vas avoir une relation sur le long terme, et à ce moment-là, ils vont investir un peu plus de temps pour te garder. Mais quand tu passes par une agence, il y a forcément une énorme perte de connaissance entre ce que tu dis à l'agence et les modifications. En résumé, il faut essayer d'avoir un peu une connaissance de ces métiers-là et on a besoin que les heads of voire les C level fassent preuve de curiosité pour cet aspect du Produit au même titre que pour le dév. Les facs françaises forment des linguistes qui sauraient faire ça très bien si les entreprises savaient où les chercher. On a un problème pour intégrer ces savoir-faire dans des équipes UX ou des équipes produit. On se retrouve avec des ouvertures de pays qui ratent complètement sans que le niveau de connaissance des processus de traduction et localisation progressent. Chez Sendinblue, j’ai poussé pour le recrutement d'une personne à temps plein qui devait s’occuper de ça et nous aider lors du lancement des projets à faire un glossaire (un élément clé du design system) qui va servir à préparer la traduction autant du côté marketing que produit. Souvent on a le marketing qui vend un produit en lui donnant un certain nom, mais au sein d'une équipe produit, et bien, depuis le début, le projet porte un autre nom. Pour illustrer tu te retrouves avec le marketing qui va te vendre des pommes, et une fois que tu es dans le produit, c'est des oranges. Maintenant, comment tu vas trouver tes fruits si en plus sur la langue que tu utilises, il y a une ambiguïté et un seul mot pour dire pomme et poire ? C'est un vrai sujet et c'est un sujet pour lequel il faut investir un peu dans peu de temps. La bonne nouvelle, c'est qu'un glossaire, c'est certes du temps mais ce ne sont pas des outils incroyables non plus.
Je pense qu'il faut embarquer tôt toutes les personnes qui jusque-là faisaient des tâches qui vont nous être réservées. Sinon, sans ça, le défi est d’affronter de la résistance.Donc essayer d'identifier les personnes qui faisaient le contenu. Tu as plusieurs typologies. De manière un peu mécanique, tu as la personne qui le faisait, et ça l'embêtait. C'est souvent les PM. Ils adorent nous voir arriver. Les designers entrent aussi souvent dans cette catégorie-là. L'autre catégorie qui est un peu plus compliquée à gérer, c'est les personnes du marketing qui adorent écrire pour le produit, mais qui souvent le font avec une approche marketing qui ne s'accorde pas avec des besoins produit. Et ça, c'est un peu plus compliqué à rattraper. Donc il faut essayer de leur expliquer ce que tu fais, pourquoi tu vas le faire. Il ne faut pas les challenger directement sur l’écriture. On se dit à ce moment-là tu rentres dans une querelle entre ancien monde, nouveau monde. La réponse que tu reçois la plupart du temps, c'est "Oui, mais on a toujours fait comme ça". C'est très difficile d'en sortir sans dévaloriser le travail qui a été fait jusqu'à présent. Ce travail a bien sûr été fait en toute bonne foi. La personne du marketing qui s'occupait de rédiger le produit n'était pas là pour torpiller le produit ! J'ai remarqué qu'on s'en sort plus facilement en parlant de problématique d'internationalisation ou d’accessibilité. On va avoir une copie en anglais et on va dire "Là ça marche très bien, mais regarde le site en allemand".Là souvent les gens tombent de très haut en allant voir le site sur des langues qui sont moins synthétiques. Cette technique permet de mettre en avant le fait qu'il va falloir choisir des éléments signifiants et actionnables plutôt que de récupérer des promesses marketing. Selon les objectifs de la boite pour laquelle tu travailles en termes d'accessibilité, ça peut être un levier intéressant de mettre en exergue les lacunes du contenu qui n'est pas conforme aux problématiques d'accessibilité. Souvent, les personnes du marketing à ce moment-là se découragent un peu et te refilent le bébé tranquillement. Cela permet d'éviter de les aborder frontalement en leur disant "maintenant c'est moi !", en prenant le risque qu'elles s'y accrochent.
Pour éviter des tensions dans le travail, on peut vouloir rejoindre une entité UX plus mature. Ce sont souvent des personnes qui savent qu'elles ne vont pas t'attirer en te disant "Rien n'est prêt et j'ai besoin de toi" qui te recrutent. Néanmoins il me semble qu'il y a des questions assez concrètes à poser. Demander, par exemple, quels sont les objectifs annuels ou trimestriels selon le fonctionnement de l'équipe des leads ? Déjà, tu mets un peu les pieds dans le plat... Tu peux poser des questions sur les KPIs contenus. Cette question fonctionne mieux s’il y a déjà une équipe d'UX writers. Et c'est rare ! Particulièrement dans l'écosystème français. Donc si tu poses cette question-là et que ça bafouille en face, ça ne veut pas forcément dire que ça va être nul. Mais le développement donne une bonne idée des préjugés que tu vas devoir combattre. Tu peux aussi demander concrètement combien il y a de Tribes et quels sont les objectifs de recrutement en contenu. Si tu vois que le projet est de n’avoir qu’une personne pour l'UX writing et qu'il y a sept ou huit Tribes, ça devient compliqué. En plus s'il n'y a pas d'objectifs de recrutement, ça veut dire que tu vas te retrouver avec la relecture d'écran déjà finalisée. Et tu risques d’avoir du mal à évoluer vers une inclusion dans le cycle de design. Tu peux aussi demander comment est gérée la traduction, s’il existe des données sur les langues qui génèrent plus de revenus. La pire réponse, c'est "les PM se débrouillent". Alors là, tu comprends que les PM font de leur mieux, mais qu'en fait iels ne se débrouillent pas. Évidemment tu ne demandes pas ça au premier entretien avec les ressources humaines, mais ça donne une bonne idée. Tu peux aussi aller chercher le ou la Head Of ou Lead sur LinkedIn pour chercher à comprendre la structure et son ancienneté. C'est sûr que si l'équipe UX a six mois et que l'entreprise à une dizaine d'années, ça donne une bonne idée des tensions qu'il peut y avoir en interne.
C’est la question de l’intégration à des équipes qui se pose. Toute discipline de l’UX a des KPIs et c’est très sain à condition d’arriver dans une équipe ouverte à nos méthodes de travail. D’après moi, c'est un peu un piège dans lequel on tombe souvent dans les métiers de l'UX lors de la construction d’une équipe. On nous fait venir dans une entreprise pour faire des choses, potentiellement dans le cadre d'une transformation digitale dans les grands groupes. Il faut à la fois qu'on fasse les choses et qu'on prouve pourquoi on ne les fait pas comme avant, tout en essayant d'entretenir de bonnes relations avec des collègues qui faisaient les choses “à l'ancienne.” Cette situation-là, elle est pratiquement insoluble. Cette question doit être en cours de résolution quand on arrive. Si en arrivant, on doit continuer à prouver pourquoi on est là, ça installe sur le moyen terme, une ambiance de travail assez délétère. De mon expérience, ça force à se demander, fondamentalement, qu'elle est notre valeur ajoutée. Tu peux un peu tâter le terrain en entretien d'embauche, et arriver à savoir si: On vient te chercher avec une vision un peu restreinte de l'UX writing, où on va s'attendre à ce que, en te donnant des écrans finis, toi tu relises et que tu harmonises. Ce qui n'est pas passionnant et pas le plus intéressant de ce qu'on a à proposer. Ou s'il y a un questionnement un peu plus profond sur ces sujets-là. Ou bien encore s'il n'y a pas encore le questionnement, si tu peux aussi accompagner l'entreprise sur ce terrain-là. Finalement, avec l'expérience, tu arrives assez facilement à voir où on t'imagine et où tu vas pouvoir aller.
Quand j’ai commencé, j'aurais voulu avoir une idée un peu plus précise de ce que sont les salaires dans les équipes UX. Parce que mon parcours relève de la fac en Langues et pas d'une école donc je n'étais pas préparée aux salaires de designer et je pense que je me suis longtemps sous-vendue. C'est mon impression ces dernières années mais l'UX s’ouvre de plus en plus à des profils universitaires qui n’ont pas la connaissance des tarifs dans le privé. En recherche, pas mal de personnes qui arrivent de la sociologie ou de l'anthropologie. L’UX writing, c'est très atypique, il n'y a pas une formation qui y mène et pas de préparation aux attentes salariales.
On a 2 très belles réussites chez IA Marketing et IA Medical. La première, c'est la transformation d'un formulaire extrêmement complexe en chatbot. Nathalie un des premiers chatbot d’ IA Marketing, a permis une hausse de 400% du taux de conversions sur une cible pas toujours simple en digital les retraités.
Dans le cas du développement de Nathalie nous avons amorcé une étude quantitative et qualitative des données de notre partenaire.
Elle s’est déroulée en plusieurs temps :
Etude et Audit de l’ergonomie du site web et du formulaire
Pendant cette phase nous avons réalisé une étude quantitative qui nous a permis de voir quels étaient les points de frictions de manière quanti avec des indicateurs classiques : taux de rebond par appareils et par page d’attérissage, taux d’abandon dans le formulaire, coût d’acquisition par appareils.
Ensuite nous avons enregistré plusieurs centaines de cessions pour valider les hypothèses soulevées par la donnée quantitative. Ce qui nous a permis de voir qu’il y avait des soucis de compréhension de certains champs, que certains arrivé pre-rempli ou noté en obligatoire et générés des erreurs, etc etc.
Enfin nous avons utilisé des algorithmes pour analyser les bases de données mails et enregistrements des conseillers. Cela nous a permis de comprendre qu’il était fondamentale d’imprimer une image de marque forte dans l’esprit de l’usager, car il fait beaucoup de demandes dans une journée et que parfois il ne s’attend pas au rappel. C’est ce qui nous a permis de rajouter la question “ Quand préférez-vous être recontacté par nos équipes”.
Étude de la base de données clients
Nous avons utilisé plusieurs algorithmes pour segmenter la base de données et voir quels étaient les profils qui étaient les plus intéressants mais aussi avec lesquels les dossiers arrivaient avec le plus d’erreurs de complétions.
De nombreux dossiers sont mis de côté car l’usager a “mal rempli” les champs, le formulaire de rachat de crédit étant quelque chose de très complexe à gérer et demandant pas mal de chiffres. Il est courant que la personne confonde son net mensuel et son net annuel.
Toute cette étude nous a permis de construire des parcours adapté mais aussi de développer de nouvelles fonctionnalités comme le blocage du clavier mobile sur les chiffres quand une donnée quantitative est demandée.
Le client avait de nombreux a priori sur l’adoption de la technologie par les seniors et le mobile était le canal d’acquisition le moins rentable.
La hausse du taux de conversion, couplé à une meilleure complétion du formulaire ont permis de changer cette situation. Aujourd’hui c’est un canal d’acquisition rentable car il apporte de très bons dossiers et correctement complété.
Le chatbot a permis de démontrer :
L’importance de l’analyse quantitative et qualitative en amont du projet
L’importance de la sémantique pour chaque typologie d’usagers
L’importance de la segmentation du parcours
La seconde réussite c’est le projet mon Bot prévention Suicide.
Un projet financé par l’ARS Auvergne Rhône Alpes et porté par la fondation ARHM et l’IRJB. Le donneur d’ordre souhaitait mettre en place une stratégie multimodale de la prévention du suicide avec pour objectif de repérer et de maintenir le lien avec les personnes en souffrance et de les orienter vers les ressources appropriées.
Nous avons axé la réponse à l’appel d’offre sur deux points :
Les workshop de co-conception
La formalisation d’une base de données des ressources
Le projet a demandé plus de temps qu’à la base, mais nous avons réussi à créer une solution multimodale qui répond aux besoins du terrain.
A la suite du déploiement de la solution nous l’avons soumise à l’appréciation des usagers. L’objectif du test était de mesurer l’appréciation de « mon bot prévention » auprès des utilisateurs finaux.
Plus précisément, il s’agissait d’avoir un retour à la fois sur l’ergonomie de cet outil, autrement dit de vérifier s’il était facile à utiliser et d’identifier les éventuels points de blocage pour effectuer la recherche, ou en matière de design.
Plusieurs utilisateurs ont exprimé leur avis sur le chatbot (dont des usagers, des accompagnants proches et des accompagnants professionnels).
De manière globale, la version digitale des répertoires en prévention du suicide a été considérée par les participants comme étant facile à utiliser. Plus précisément, tous les usagers et accompagnants proches qui ont utilisé le chatbot pour effectuer leur recherche ont considéré cet outil comme facile à utiliser.
50% des professionnels ont considéré également le chatbot comme étant l’outil le plus facile à utiliser comparativement aux annuaires et à la page web.
Une des verbatims qui pour l’équipe résume l’impact de la solution digitale et du chatbot dans le quotidien des soignants :
En tant que manager comment montrer la valeur de notre équipe d’UX writer grâce au KPI ?
On veut montrer que c’était l’UX Writer qui a eu un impact, et pas juste un ressenti que les gens autour ont bien aimé cette collaboration. Mais quelque chose d’un peu plus chiffré.
Mon expérience me dit que souvent que ça ne va pas être forcément grâce à une nouvelle fonctionnalité sur laquelle on va travailler, mais c’est plutôt d’identifier les endroits existants de l’expérience qui n’étaient pas optimales et de réécrire quelque chose comme une push notif, où l’on voit qu’un comportement change derrière.
En tant que manager, c’est super important car ne pas montrer l’impact, tu ne fais pas grandir ton équipe.
Mike Winnington
· UX Writing Manager
· il y a 1 an
Posez des questions sur les ratios, les projets actuels, le besoin de ce rôle, la vision de l’équipe UX Writing
Déjà, je voulais savoir plus sur l’équipe, sur les ratios UX writer, product designers et PM parce que ça indique l’attention qui est donnée à ce métier.
Savoir un peu plus sur les challenges et les projets actuels sur lesquels on travaille et on va travailler.
Ça m’a vachement donné plus d’informations, et vu que c’était en appel privé, j’imagine qu’il y avait peut-être certaines choses qui étaient dévoilées et qui ne seraient peut-être pas à dévoiler pendant une présentation, pendant une conférence ou un podcast.
Chez Getaround, j’étais le premier UX writer.
Du coup, on peut se dire que c’est plutôt bon signe parce que ça veut dire que la boîte a identifié un besoin, mais il faut se méfier.
Il faut être sûr qu’ils ont bien compris le rôle et le métier aussi. Pour les mini choses qui peuvent être possibles juste en lisant l’offre, c’est :
Qui serait mon manager ?
Est-ce que je vais être dans l’équipe design, ce qui me paraît logique ? Ou est-ce que je vais dans l’équipe marketing qui ne me paraît pas logique ?
En tout cas, ça peut être dès fois les missions qu’on peut voir par rapport au job. Chaque boîte est unique. Du coup, je pense qu’il y a aussi des raisons pour lesquelles il y a des structures comme ça, mais juste pour moi, ça peut être quelque chose.
Ensuite lors des entretiens ; de savoir pourquoi maintenant ?
Comment ils se sont rendu compte qu’il y avait ce besoin-là ?
Je pense que dans ces cas-là, lorsqu’il n’y a pas de UX writer existant, si c’est une application et qu’on fait des tests au sein de l’application et on voit que la qualité est terrible, peut-être que c’est aussi à cause de ça qu’ils recherchent quelqu’un.
S’il y a une énorme équipe UX writing et qu’on voit pas mal de choses qui ne sont pas optimales, ça peut montrer que c’est quand même un sacré challenge qui n’est pas forcément négatif, mais ça peut montrer aussi qu’il y avait certains éléments au sein de la boîte qui ne sont pas très efficaces et que les gens négligent peut-être la qualité, qu’ils veulent juste shipper rapidement…
Souvent, on a un feeling en parlant avec les gens et il faut suivre un peu son intuition.
Mais il ne faut pas avoir peur de poser des questions qui peuvent mettre mal à l’aise, par exemple :
Une amie qui passait des entretiens ces derniers temps m’a dit qu’il faut toujours demander c’est quoi la vision de la boîte par rapport au métier en question ?
Parce que ça va être en parlant avec des gens en face qu’on va savoir jusqu’à quel point il y a une maturité ou pas par rapport à la vision du métier.
Si je posais cette question en tant que candidat pour devenir manager, je saurais :
Ce que mon manager pense de mon métier.
Comment cette personne voit les choses ?
Si je posais cette question en tant que contributeur individuel, j’en saurais un peu plus par rapport à mon manager et dans quelle voie cette personne me mènerait.
Ça peut être hyper important et des fois, ça peut être une question encore plus importante pour les contributeurs individuels.
Lorsque l’on change de boîte, ça peut être parce qu’on est attirés par la mission, mais ça peut aussi être parce qu’on aimerait bien monter en compétence car on n’arrive pas à monter en compétence dans notre boîte actuelle.
Si on pose la question par rapport à la vision du métier et que la personne en face donne une réponse qui montre que c’est moins mature que ma boîte actuelle, peut-être que je n’aurais pas l’opportunité de monter en compétence. Je n’ai jamais testé cette question, mais mon amie a peut-être raison. C’est une vraie question qui devrait toujours être posée en tant que candidat.
Mike Winnington
· UX Writing Manager
· il y a 1 an
Chez Getaround et Doctolib, j’ai mis en place un framework de collaboration où l’UX Writer adopte un rôle owner, partner ou consultant. Ce framework a été inspiré par un article de Bronwyn Berkery et j’ai également écrit mon propre article sur ce sujet.
C’est quelque chose que j'avais fait aussi au sein de Getaround en tant que contributeur individuel parce que j'étais le seul UX writer et du coup, je devais gérer toutes les demandes.
Lorsque tu es la seule personne, ce n’est pas possible de suivre tous les projets à la même vitesse et avec la même implication.
J’ai trouvé un framework de collaboration de owner/partner/consultant. C’est-à-dire :
Est-ce que je vais vraiment prendre le l’ownership de A à Z sur l’UX writing de ce projet ? Dès le début jusqu’à la fin.
Ou est-ce que je vais m’impliquer un peu plus tard en tant que partenaire, mais quand même assez tôt dans la phase define (du double diamond) ?
Est-ce que ça va être plutôt un travail de collaboration entre les product designers et les PM où ils vont mettre leur cerveaux ensemble et je suis là en support en tant que consultant ?
Au début, en arrivant chez Doctolib, je me disais ce qui marchait pour moi chez Getaround, en tant qu’une personne qui bossait avec 6 squads différentes et trois product designers, ça ne va pas fonctionner dans une boîte comme Doctolib où on a presque cinquante, peut-être soixante-dix squads.
Les gens au sein de mon équipe avaient un peu ce même problème où il y avait trop de projets en même temps, où ils avaient du mal à les différencier et à prioriser quels étaient les projets sur lesquels ils devaient passer plus de temps que les autres.
Du coup, je me suis dit que ce framework n’était peut-être pas mal.
J’ai parlé avec mon ancienne manager de Getaround qui m’a m’a dit :
“Franchement, ce framework, ça marchait trop bien. J’ai exactement la même chose avec cette nouvelle user researcher parce que c’est le même genre de situation où on peut avoir énormément de demandes.”
Le fait qu’elle me fait ce retour, je me suis dit que c'était peut-être assez solide comme framework. Du coup, j’ai expérimenté jusqu’à quel point ça marche sur une échelle un peu plus grande. (et c’est encore en cours)
En tant que manager, je joue un peu le rôle de consultant où on a des créneaux dans nos agendas que les membres de l’équipe peuvent réserver pour faire une content critique, pour faire un pair review, et d’autres moments pour présenter le travail en cours. En réalité, je joue un peu le rôle de consultant avec le travail.
Pour prioriser, entre owner/partner/consultant lorsque j’étais chez Getaround on observait dans un premier temps ce qui était dans la roadmap et je notais les projets selon des critères d’exclusions ou non:
Est-ce que ce sont des problématiques qui sont déjà connues au sein de la boîte ou pas ?
Si on est en train d’aborder de nouveaux problèmes, je pense que je devrais être là
Si ce sont des problèmes reconnus, peut-être plus apprises sur des connaissances existantes, je considérais que les product designers et PM devraient être un peu plus à l’aise. Ces deux-là sont assez liés, ils connaissent bien ces utilisateurs ou pas.
Si c’était un nouveau type d’utilisateur, je pense que je devrais être là, Si c’est le type de base qu’on met dès le début et qu’on connaît bien, à ce moment-là, je pense que les product designers et les PM peuvent être un peu plus autonomes.
Du coup, c’est aussi lié sur est-ce que c’est un sujet sensible ou pas ?
Si les risques étaient plutôt élevés, je bascule plutôt vers owner
Si les risques étaient plutôt négligeables, je peux accepter d’avoir un peu moins la main dessus.
C’est hyper dur d’accepter de ne pas avoir le contrôle, néanmoins il faut garder en tête que l’on est en train de créer des logiciels.
On peut modifier les libellés après si besoin. Si tu es en train d’imprimer des magazines c’est plus dur à rattraper à ce moment-là, donc tu as de la marge de manœuvre (selon le projet).
Mike Winnington
· UX Writing Manager
· il y a 1 an
Le rôle d’un.e UX Writer, ce n’est pas vraiment de simplement écrire mais plutôt réfléchir et challenger.
Il y a un moment que j’ai vraiment en tête et où je me rends compte que j’étais peut-être un peu naïf. Quand j'étais chez BlaBlaCar, je m’occupais surtout de notre centre d’aide, pour rédiger des templates que les agents dans l’équipe support utilisaient base pour les aides aux tickets.
C'est à ce moment-là où j’ai découvert un peu le monde du produit et de l’UX, et c’était à ce moment-là où j’ai essayé de passer de plus en plus de temps possible à m’entourer avec des gens de l’équipe produit.
C’était déjà bien pour synchroniser par rapport à mon travail de rédaction de l’outil de support, mais je voulais arriver un peu plus tôt dans le cheminement et vraiment être dans une équipe produit et design.
Du coup, j’ai commencé par remplacer les UX writers quand ils étaient en vacances, et je pense que j’avais tellement envie de faire ça au quotidien, que je me lançais trop dedans.
C’est-à-dire que s’il y avait de la copy à écrire, j’essayais de rédiger. À ce moment-là, je n’avais pas forcément compris que le travail en tant que UX writer n’est pas forcément un travail rédactionnel.
C’est aussi de remettre en question ce qui est la bonne solution, si tu te sers des bons composants et des bons patterns.
Tout au début, j’essayais de rentrer trois messages à la fois dans très peu d’espace, et je n’avais pas compris pourquoi je n’arrivais pas à être concis.
Après, en y repensant j’ai compris que c’était car le design n’était pas le bon, et je ne challengeais pas assez ce que j’avais devant mes yeux.
C’était un peu de la naïveté à ce moment-là parce que je voulais montrer que j’étais capable. Pour moi, être capable c’était d’avoir un peu de magie et de mettre trois messages dans très peu d’espace, alors que ce n’était pas forcément la bonne démarche aussi.
Mike Winnington
· UX Writing Manager
· il y a 1 an
