![](https://api-ux.wikihero.org/storage/user-avatar/df877f38/Gig9YprOl6V4xcmI.png)
- merci! Utile
- Pas utile
- Pas sûr
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur l'UX writing.
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 : 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 : 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 : 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). 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.
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. 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 : 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 : 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 : 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.
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 : 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: 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).
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.