Trio de choc : la collaboration entre Product designer, Product manager & UX writer

Trio de choc : la collaboration entre Product designer, Product manager & UX writer

image
Dans cet épisode du podcast UX Content Craft, Apolline Rouzé* (animatrice du podcast), UX writer, Cassandra Mansiamina, Product designer, et Fanny Laverty, Product manager partagent la manière dont elles collaborent sur un projet chez Qonto.

*Pour éviter de parler de moi à la troisième personne dans cet article, permettez-moi d’utiliser la première personne du singulier 😊

Trio de choc : la collaboration entre Product designer, Product manager & UX writer

Dans ce nouvel épisode de podcast, j’accueille Cassandra Mansiamina, Product designer senior, et Fanny Laverty, Product manager experte, toutes deux chez Qonto.

Vous le verrez, c’est un échange à 3 voix, puisque j’y interviens.

Ensemble, on parle de notre collaboration, et de la manière dont on articule nos différentes expertises, à travers toutes les phases de conception, avec, toujours en trame de fond ce qu’on appelle le « Qonto Way ».

Note : on a enregistré cet épisode en mars 2023. Ce n’est que maintenant que je prends le temps de le publier.
  • Cassandra était alors Product designer junior, et Fanny Product manager senior. Toutes deux ont bien sûr évolué depuis notre conversation (et moi, si vous ne le saviez pas encore, j’ai quitté Qonto en septembre 2023).
  • Les phases et méthodes de conception chez Qonto ont elles aussi un peu évolué.
  • Pour autant, notre discussion reflète tout à fait notre collaboration et le Qonto way.
  • Cassandra et Fanny m’ont d’ailleurs dit que cet épisode est comme une rétrospective, une prise de recul, pour se rendre compte du chemin parcours. Et quel chemin !

Bonne lecture ! ☕

🎧 Si vous préférez écouter l’épisode de podcast que le lire en article, rendez-vous sur votre plateforme d’écoute préférée.

→ Écouter l’épisode du podcast UX Content Craft

Interview — La collaboration entre Product manager, Product designer et UX writer 🎙️

Apolline – Commençons par le commencement : faisons les présentations.

Fanny – Je suis senior Product manager (PM) chez Qonto, depuis février 2022. Auparavant, j’étais ingénieure en propulsion spatiale pendant 12 ans. Rien à voir avec mon métier actuel et le secteur financier. Je me suis reconvertie au métier de Product manager juste avant de rejoindre Qonto.

Cassandra – Je suis Product designer chez Qonto, que j’ai rejoint début 2022 également. Et c’était aussi une reconversion. J’étais team lead d’un support client, métier que j’ai adoré car j’étais au contact des clients. Mais j’avais envie de mettre le nez dans le produit, de participer à la conception. Dans mon ancienne boîte, j’ai échangé avec plusieurs Product designers, ce qui m’a donné envie de me réorienter vers ce métier.

Apolline – Vous n’avez aucun élément de comparaison : c’est la première fois que vous bossez avec le métier de l’une et l’autre et la première fois que vous travaillez avec une UX writer.

C’est tout l’objet de cette conversation : parler de la collaboration entre nos trois métiers, et notamment avec l’UX writing.

Alors, entrons dans le vif du sujet : avant de travailler avec un ou une UX writer, c’était quoi votre vision du métier d’UX writer ?

Fanny – Pour être honnête, je n’en avais pas entendu parler avant d’arriver chez Qonto, je ne savais pas qu’un tel métier existait. Pour moi, l’UX writing relevait de la compétence du designer.

La première fois où j’ai bossé avec un UX writer, j’ai surtout vu l’expertise sur l’écriture, mais ça s’arrêtait là. Cette vision a rapidement changé au fur et à mesure des projets et de la croissance de l’équipe d’UX writers.

Cassandra – La première fois où j’ai entendu ce terme, c’était lors de ma formation en product design chez The Design Crew. J’ai d’abord surtout intégré le mot « writing » : pour moi, ce métier servait à écrire dans une interface. J’avais une vision très réductrice. Qui a aussi rapidement changé en bossant avec des UX writers.

Apolline – Comme l’équipe d’UX writers est conséquente chez Qonto, vous avez vite entendu parler de cette discipline.

Replongeons-nous dans votre mémoire : comment s’est passée votre toute première collaboration avec un ou une UX writer ?

Fanny – J’ai clairement sous-estimé l’importance du choix des mots. Je n’avais pas encore en tête ce que cette expertise pouvait apporter à toutes les phases de conception.

Cassandra – Idem, je n’avais pas conscience de l’impact des mots et de la place qu’ils pouvaient prendre ou ne pas prendre. Et, je me souviens avoir bossé sur une version responsive sur mobile, et l’UX writer a permis d’adapter la solution à la contrainte d’espace.

Apolline – Selon vous, qu’apporte l’UX writing au produit ?

Fanny – Je trouve que, dans la phase de réflexion et de recherche, l’UX writing donne un éclairage assez poussé sur la psychologie des utilisateurs et utilisatrices. Comment ils et elles peuvent réagir face à certains mots, ou comment ils et elles comprennent certaines formulations.

On se complète beaucoup entre PM et UX writer, sur la façon dont on perçoit les utilisateurs et utilisatrices. J’ai une vision fonctionnelle du produit, d’une expérience, quand l’UX writer a une meilleure compréhension de la psychologie des utilisateurs et utilisatrices.

Cassandra – On parle généralement du binôme Product designer/Product manager, mais on ne parle pas assez du binôme Product designer/UX writer, qui, certes, reste rare mais qui est, pour moi, le combo gagnant. Travailler avec un ou une UX writer m’apporte beaucoup, on se complète énormément. Mon plus grand souhait est d’avoir la possibilité de travailler à chaque fois avec cette expertise et ce, dès le début du projet. L’UX writer apporte systématiquement une nouvelle perspective.

Bref, je suis votre fan n°1 ! (rires)

Apolline – Aujourd’hui, comment l’UX writing a contribué à développer vos compétences et à améliorer votre travail ?

Fanny – Cela m’a permis d’affiner ma compréhension de l’expérience utilisateur et la conception d’un parcours.

Aussi, je vois bien qu’en tant qu’utilisatrice je suis sensible aux mots. Alors, me familiariser avec l’UX writing me permet d’accorder une attention particulière au choix des mots.

Cassandra – Quand j’analysais la concurrence, je regardais l’UX et les composants utilisés, et maintenant j’accorde beaucoup plus d’attention aux textes, aux mots et expressions de mots choisis.

Petite anecdote : quand j’étais en formation chez The Design Crew, on devait travailler un parcours, c’est-à-dire à la fois les composants et le contenu écrit, et je me suis bien rendue compte qu’on ne pouvait pas écrire n’importe quoi. Pourtant, même si j’étais convaincue que ce que j’avais écrit était clair, en testant le parcours, j’ai réalisé que la navigation n’était pas claire pour les utilisateurs et utilisatrices.

Apolline – Passons à présent au concret : comment on collabore toutes les trois, pour une expérience utilisateur qualitative. Chez Qonto, le processus de conception diffère légèrement de ce qui est globalement intégré dans les équipes design (je parle du classique Recherche / Idéation / Conception / Analyse).

Un projet est lancé selon sa priorisation vis-à-vis des objectifs annuels, puis trimestriels de l’entreprise.

Alors, Fanny, je me tourne vers toi pour commencer par le commencement : comment est priorisé un projet plus qu’un autre ? Pourquoi choisir de lancer celui-ci plutôt qu’un autre ?

Fanny – C’est une décision collective, prise selon les objectifs de l’entreprise et les retours des utilisateurs et utilisatrices. Il s’agit donc de faire correspondre ces objectifs business aux besoins utilisateurs (et vice versa).

On part d’un objectif, et on enclenche une phase de pré-recherche : qu’est-ce que cet objectif veut dire d’un point de vue utilisateurs ? Quels sont leurs besoins vis-à-vis de cet objectif ? Comment celui-ci peut apporter de la valeur aux utilisateurs et utilisatrices ? Comment peut-on les aider ? Pour apporter des premiers éléments de réponses, on collecte de l’information auprès de ces derniers et auprès d’experts.

On priorise alors le sujet qui apporte le plus de valeur, pour orienter le prochain projet – améliorer telle ou telle fonctionnalité, l’ouvrir à d’autres utilisateurs, ou créer un nouveau parcours.

Apolline – J’en profite pour préciser que nous travaillons toutes les trois sur l’onboarding : inscription sur Qonto, création de compte, et aussi dépôt de capital – de l’inscription jusqu’à la première transaction. Donc nous travaillons plutôt sur l’amélioration de cet onboarding dans les différents marchés, mais nous pouvons être amenées à adapter le parcours selon les formes juridiques des entreprises, et à créer de nouvelles fonctionnalités cross-plateformes avec différents partenaires (par exemple, avec des LegalTech pour la création d’entreprise). Finalement, on ne dirait pas, mais l’onboarding est très vaste sur Qonto.

Revenons à nos moutons : après avoir choisi le problème à traiter, démarre la phase de Value Analysis (VA). Fanny, je te laisse l’expliquer ?

Fanny – Dans cette phase, nous étudions en détail le problème. On établit une photo précise de l’état actuel des choses : comment, aujourd’hui, l’utilisateur fait (ou ne fait pas) pour résoudre ce problème sur Qonto ou ailleurs, entièrement ou partiellement. Cette phase vise à avoir une idée argumentée de la valeur qu’on va pouvoir créer.

Bien sûr, on définit les indicateurs de performance qui nous permettront d’analyser le succès de cette nouvelle expérience.

Tout ce que l’on fera, à chaque étape du processus de conception, doit être guidé par la valeur que l’on veut créer et les objectifs chiffrés que l’on veut atteindre.

Cette phase de VA est menée a minima par le ou la Product manager et le ou la Product designer (PrD). L’UX writer y participe parfois – on aimerait que ce soit tout le temps, mais ce n’est pas encore possible aujourd’hui, puisqu’il y a moins d’UX writers que de PM ou PrD.

Cassandra – Avoir une visibilité sur la situation actuelle du produit est primordial, pour comprendre ce qu’on peut améliorer et pour définir quelle partie de l’expérience est alors prioritaire, à améliorer ou concevoir en premier.

Il y a aussi toute une partie benchmark, pour analyser la concurrence – qui est notamment réalisée par le ou la Product designer, éventuellement en binôme avec l’UX writer.

Le benchmark nous permet de voir les points forts de la concurrence, dont on peut s’inspirer et tirer des apprentissages et des idées, mais également les points que l’on considère faibles qui sont des opportunités pour nous. On observe les étapes du parcours, la navigation, et les composants utilisés. C’est d’ailleurs très important d’être à jour sur les composants et comportements utilisés ailleurs.

Apolline – Lorsqu’on est amené à faire ce benchmark ensemble – Product designer & UX writer – je suis alors plus concentrée sur les mots et expressions clés utilisés, les termes techniques et légaux, les explications qui sont données, ainsi que les actions qui sont demandées dans le parcours.

Fanny – Et de mon côté, en tant que PM, je vais aussi me concentrer sur l’analyse de données, pour comprendre les comportements actuels des utilisateurs et utilisatrices, la population à laquelle on souhaite s’adresser, et ses caractéristiques.

Si l’UX writer est impliqué dans la phase de VA, on va travailler ensemble sur les préférences utilisateurs, en s’appuyant notamment sur le recueil de verbatims. Si on n’a pas assez de verbatims, on peut réaliser des interviews auprès d’utilisateurs et utilisatrices cibles. Cela nous permet de comprendre leurs attentes, leurs frictions et leurs émotions.

Quand on parle aux utilisateurs et utilisatrices, on peut avoir de vraies surprises auxquelles on ne s’attendait pas. On ne pensait pas qu’ils et elles avaient compris telle chose comme ceci ou comme cela.

Apolline – Pendant cette phase de VA, il y a aussi toute une partie où l’on explore à fond le sujet. Si par exemple, on souhaite ouvrir l’application à un nouveau statut juridique d’entreprise, il est important de connaître ses caractéristiques, ses subtilités et son jargon. Et bien sûr, il est primordial de connaître les contraintes légales qui y sont liées – et là, l’équipe juridique est notre meilleure amie !

Fanny – Oui, c’est un gros travail à faire pour éviter que l’utilisateur ou l’utilisatrice ne soit bloqué dans son parcours par manque de compréhension. Le côté légal et le jargon ne doivent pas être des obstacles. Quand on n’est pas clair, le risque d’abandon est grand. C’est un vrai challenge.

En résumé, la phase de VA, c’est de décrire précisément le problème, définir là où l’on souhaite aller, explorer au maximum les besoins et attentes des utilisateurs et utilisatrices (qui sont notre moteur), explorer ce que fait la concurrence, et imaginer quelques premières pistes de solution.

Apolline – On va condenser toute la recherche réalisée dans ce qu’on appelle un concept paper – un document accessible à toutes les parties prenantes du projet, pour bien comprendre ses tenants et aboutissants.

C’est sur ce document que l’on va se baser pour attaquer la phase suivante : la Value Engineering – une phase très intense, déclenchée par un kick-off.

Fanny – La Value Engineering (VE), c’est la phase de conception. On connaît bien le problème, on sait quels objectifs et succès on souhaite atteindre en résolvant ce problème, mais, pour le moment, on ne sait pas encore comment on va le résoudre. On a quelques pistes de solution en tête grâce à la recherche.

Pendant cette nouvelle phase, on va donc décider tous ensemble la solution la plus adaptée. Quand je dis tous ensemble, c’est : PM, Product designer, UX writer, développeurs et développeuses, expert métier, expert légal, etc. Cela permet de pouvoir répondre à toutes les questions que l’on se pose lors de la conception : quelqu’un a forcément la réponse.

Aussi, cela permet d’avoir des retours rapides des ingénieurs sur la faisabilité technique des solutions proposées par le design.

En tant que PM, je vais bien sûr être assez vigilante sur le coût en développement. On veut atteindre un certain succès, mais on ne veut pas passer trop de temps à développer la solution. Il y a un compromis à faire entre le coût et le succès que l’on vise.

La phase de VE est très condensée, où toutes les parties prenantes sont focus sur ce seul projet. Cela nous permet de concevoir rapidement. C’est intense, mais très riche.

Apolline – On a beaucoup d’ateliers pendant cette phase, pour résoudre des problématiques qui pointent leur nez quand on imagine les solutions possibles. Les développeurs et développeuses sont présents. D’ailleurs, je pense que c’est à leurs côtés que j’ai le plus appris. Car ils et elles voient tout : les chemins possibles, les erreurs possibles. En tant que designer, c’est impossible d’imaginer tous les cas particuliers, seul·es.

Cassandra – En tant que Product designer, la phase de VE est la plus challengeante, parfois stressante, mais la plus intéressante bien sûr.

Quand on rentre dans cette phase, on sait pertinemment que le premier atelier design est rarement final (rires). Lors des premiers ateliers design, je ne m’attends pas à avoir la solution à l’issue des échanges, mais c’est vraiment le moment de tout entendre, de s’écouter les uns et les autres, d’imaginer tous les cas particuliers possibles et d’aborder les questions de faisabilité technique et de coût.

En arrivant chez Qonto, pour ma première expérience de Product designer, j’avais peur de parler aux tech (rires). Mais au fur et à mesure des projets, j’ai été de plus en plus à l’aise et j’ai compris qu’ils et elles étaient surtout des allié·es. Et on apprend énormément de leur expertise.

Alors en VE, on est ensemble, on connaît la problématique, maintenant il faut y répondre ensemble.

Apolline – C’est en effet très intense, je suis dans le même bateau que vous. En fin de chaque journée de phase de VE, je suis lessivée ! Mais j’adore la richesse de ce travail collaboratif.

Petite anecdote, je suis obligée de le dire (rires) : quand on travaille avec Fanny, pendant toute la durée de la VE, qui peut durer une semaine, deux semaines, voire un mois, elle va nous caler des créneaux dans notre Google Agenda, pour pouvoir y organiser des workshops ou tout simplement faire en sorte que l’on travaille sur le projet. Au début, c’est flippant d’avoir ton agenda rempli, mais finalement ça nous permet d’avoir du temps, d’être focus sur le projet. Et personne ne nous cale une réunion qui ne concerne pas ce projet.

Cassandra – C’est vrai que, maintenant, à cause de toi (ou grâce à toi) Fanny, je mets des placeholders dans mon agenda (rires). C’est une bonne tactique !

Apolline – Même s’il y a ces temps de travail en équipe élargie, on essaye bien sûr de se garder du temps entre Product designer et UX writer pour bosser sur la solution ensemble.

Cassandra – C’est hyper important d’être exigeant là-dessus : s’aménager des temps de travail en binôme et faire comprendre aux autres qu’on a besoin de ces moments.

On a la chance d’avoir toutes les expertises qu’il faut, et on a la chance de pouvoir travailler sur un projet à la fois. Les ateliers product design x UX writing permettent d’avancer efficacement sur la conception de la solution. J’apprécie énormément bosser avec un ou une UX writer, parce qu’à la fin de chaque atelier, on a généré des idées riches, et on a fait un grand pas vers la solution idéale. C’est une grande force.

Apolline – En plus de ces temps de travail en binôme, on a aussi besoin, Product designer et UX writer, d’avoir des moments solo pour être hyper focus sur nos expertises. Pendant ces moments-là, je cale un créneau dans mon agenda avec la mention NO MEETINGS en majuscules. Personne n’ose mettre une réunion (rires).

Cassandra – Oui, c’est essentiel pour pouvoir travailler sur nos itérations respectives.

Fanny – C’est d’ailleurs vrai pour toute l’équipe. Par exemple, les ingénieurs ont aussi besoin de temps pour mettre les mains dans le code. Pour détecter tous les cas particuliers, ceux qu’on n’avait pas anticipés lors de la première phase.

En dehors des ateliers, chaque personne doit pouvoir se concentrer sur ses tâches individuelles pour faire avancer l’équipe.

Côté product management, on en a aussi besoin pour prendre du recul, avoir une vue macro, c’est-à-dire regarder tout ce qu’il se passe – les avancées, les problèmes remontés, les décisions qui sont prises, parce que, la VE, ça grouille de partout.

Cassandra – J’ajouterais qu’il y a aussi l’étape de challenge par nos pairs. Un (ou plusieurs si nécessaires) challenge de la solution globale qu’on propose. Ce challenge a lieu quand, en équipe, on s’est alignés sur la solution. Je l’organise avec au moins ma manager et deux Product designers. Parfois, on a une bonne surprise : la solution leur semble adaptée, viable. Mais, le plus souvent, il y a des éléments à retravailler (architecture du parcours ou d’un écran, ou composants), voire la solution complète à retravailler. On a la tête dans le guidon, alors faire challenger la solution permet d’avoir plusieurs regards extérieurs qui apportent de nouveaux éléments, de nouvelles pistes de solutions.

Apolline – En effet, c’est primordial d’avoir un regard extérieur, et donc notamment au travers d’un challenge par les pairs. Pour voir ce qu’on n’a pas vu, et également pour nous permettre d’évoluer, d’améliorer notre expertise.

Si on reprend notre chronologie, à l’issue de la phase de Value Engineering, toute l’équipe projet doit être alignée sur la solution, avec un niveau de confiance élevé. Si c’est ok pour tout le monde, on passe alors en phase de Spécifications.

Fanny – La fin de VE est marquée par l’élaboration d’un planning, où l’on découpe en tâches le travail de spécifications et développement.

En Specs, l’objectif est de restituer finement ce qui a été décidé sous plusieurs formats, pour que les ingénieurs s’attaquent à la phase de développement.

Il y a d’abord un format écrit, sur Notion, qui explique tout ce qui relève du fonctionnel – et ça, c’est ma responsabilité en tant que PM. L’aspect fonctionnel, c’est le back office de l’expérience (ingénierie back-end, ainsi que les opérations qui se passent côté support client). On n’y parle pas des éléments visibles sur les écrans.

Le deuxième format, c’est ce qu’on appelle les « Visual Specs », réalisé dans Figma. Cette partie est sous la responsabilité du Product designer, à laquelle participe l’UX writer. Je suis aussi amenée à ajouter certains éléments liés au tracking et à l’interaction au clic par exemple.

Cassandra – Côté design, c’est le moment où l’on met tout au propre : le parcours idéal avec les écrans et les différents états (par exemple, l’affichage quand il y a une erreur technique, ou quand l’utilisateur n’a pas rempli un champ, etc.). Les composants avec les bonnes marges, la vérification de la couleur, etc. D’ailleurs, on fait revoir l’UI à un ou deux Product designers, pour vraiment s’assurer que tout soit parfait, au pixel près.

À côté de chaque écran, on indique l’objet de l’écran, l’objet des composants, l’interaction des éléments, le tracking, les clés de localisation pour le wording et les liens. On met vraiment tout à plat, pour que cela soit parfaitement clair pour les développeurs et développeuses, et ainsi éviter tout aller-retour entre questions et retravail.

Apolline – Côté UX writing, alors que dans la phase de VE, notre rôle est de poser les intentions de contenus et de faire plusieurs itérations, en phase de Specs, on va peaufiner la microcopie.

C’est au début de cette même phase qu’on va faire challenger les contenus par des pairs UX writers. Ici, il ne s’agit pas de challenger la solution mais plutôt le contenu, pour que ce soit le bon.

J’ajuste ensuite le texte si besoin, et je mets au propre dans la solution finale. Je m’assure bien que chaque écran a le bon texte, avec la même mise en forme. Le contenu relève de ma responsabilité.

J’ai également un travail à réaliser avec un ou une ingénieur front-end (pour les écrans) et back-end (pour les e-mails et notifications) : définir les clés de localisation, c’est-à-dire leur nom, selon une structure logique pour le code et pour le contenu.

Enfin, j’indique le nom des clés dans les Visual Specs, à côté de chaque écran.

Lorsqu’on pense avoir fini l’écriture de l’ensemble des spécifications, on les passe en revue avec les ingénieurs back-end et front-end, pour qu’ils et elles puissent s’assurer d’avoir tout ce qu’il faut pour développer la solution.

La phase de Specs est la plus courte : 2 à 3 jours en moyenne.

Ensuite, pendant que les ingénieurs commencent leur phase de développement, vient aussi la phase de localisation et de production d’illustrations si besoin (par un ou une Brand designer), ou d’autres éléments comme un article de FAQ.

De mon côté, je prépare le terrain pour la localisation : je crée les clés dans notre outil de localisation et j’y importe le texte en anglais. Je briefe mes collègues italien, allemand et espagnol pour qu’ils et elles puissent réaliser la traduction du parcours directement dans l’outil de localisation. Je réalise moi-même la traduction en français.

À l’issue, je m’assure de la qualité de la localisation : espaces, ponctuation, liens, variables, etc.

Et puis, c’est parti ! Aux développeurs et développeuses de faire leur magie (rires). Designer et UX writer sont libérées (rires).

Fanny – Alors que moi je continue jusqu’au bout, je suis la delivery. Pour m’assurer que tout se passe bien, et aider les ingénieurs si besoin. J’interviens en support, et je valide avec eux chaque tâche réalisée, selon le planning établi en fin de VE.

À l’issue du développement, c’est la phase de QA qui vise à s’assurer de la qualité de l’expérience. Ce qui a été développé est-il conforme à la solution conçue ? Est-ce que tout fonctionne bien selon des scénarios établis ? Est-ce les bonnes marges, couleurs et tailles de polices ? Est-ce que c’est responsive sur mobile ? Est-ce le bon wording, et ce dans toutes les langues ?

Cette phase, on la fait toutes les trois, chacune s’attardant sur son domaine d’expertise. On passe tout au peigne fin.

Cassandra – Chacune est responsable de ce qu’elle a produit. La qualité de l’expérience doit être irréprochable.

Apolline – Ce qui est intéressant dans une telle collaboration, c’est que, malgré l’expertise des uns et des autres, il n’y a pas de silos : on n’hésite pas à empiéter sur les platebandes des un·es et des autres. On se répartit le travail, dans la mesure du possible.

Fanny – Et on se permet de se challenger les un·es les autres.

Apolline – On a d’ailleurs la culture du challenge et non de la validation. En tout cas, c’est une validation en équipe.

Pour finir l’épisode, je vous propose quelques questions finales.

La première : aux Product designers et Product managers qui nous lisent, quels conseils leur donneriez-vous pour intégrer un ou une UX writer dans un projet ?

Fanny – Les 3 profils, Product manager, Product designer & UX writer, sont complémentaires et s’apportent beaucoup mutuellement, et ce dès la phase de recherche. L’idéal est d’intégrer l’UX writer assez tôt dans le projet, idéalement dès le lancement de la recherche. L’UX writer a une compréhension fine de la psychologie de l’utilisateur·trice.

Cassandra – Je rejoins Fanny. On part du principe que l’expérience utilisateur est unique et complexe. Alors c’est important pour chaque expertise de comprendre parfaitement le périmètre et le problème. L’UX writer a besoin de cette compréhension autant que nous, Product designer et Product manager.

Apolline – Et pour les UX writers qui nous lisent, quels conseils leur donnez-vous pour bosser avec un·e Product manager et un·e Product designer ?

Fanny – Un conseil que je donnerais : ne pas hésiter à challenger le ou la PM sur ses hypothèses, sur les profils des utilisateurs et utilisatrices, les indicateurs de performance, etc. Le challenge permet souvent de mettre en lumière des éléments auxquels on n’aurait pas pensé, ou des trous dans le raisonnement. Parfois, on peut être convaincu de certaines choses, et on ne se rend pas compte qu’il peut exister d’autres visions. Avoir un regard extérieur, notamment par le challenge, ça permet de remettre les choses en perspective et d’affiner ses connaissances, au service de la valeur que l’on va créer pour les utilisateurs et utilisatrices.

Cassandra – J’ajouterais que Product designer et UX writer ont pour but le confort de l’utilisateur·trice. Par le visuel et par l’écrit. Donc je suis aussi preneuse que l’UX writer challenge l’UX et l’UI. Et l’UX writer ne doit pas hésiter à demander à participer aux ateliers. Aussi, la communication entre les deux est clé.

Je suis absolument persuadée que Product design et UX writing est un combo gagnant !

Apolline – Merci beaucoup les filles pour cette heure passée ensemble, avec toujours autant de love ❤️

Les ressources produit et design de Fanny et Cassandra 🔍

Les ressources produit de Fanny

Les ressources design Cassandra, très podcast addict