Design & Content Systems au service de l’hypercroissance Produit @ Mirakl

[00:00:09] Pour le bouton de la modale, on met sauvegarder ou confirmer ? Je ne sais pas quel label choisir pour ce paramètre. Sur le formulaire, il faut un bouton de sauvegarde ou c'est en autosave ? Et dans les API, s'appelle comment ce statut ? On s'est pas déjà posé ces questions la semaine dernière ?
[00:00:32] Est-ce que vous aussi vous vous êtes déjà retrouvé dans cette situation, cette situation, vous avez souvent l'impression de vous poser les mêmes questions ? Et bien, ça tombe bien parce qu'aujourd'hui, on va vous parler des des solutions qu'on a mis en place chez Miracle pour éviter ces situations dans un contexte d'hypercroissance et de redesign produit.
[00:00:52] Je m'appelle Anaïs Delgado, je suis Product Design Team Lead chez Miracle. Je travaille avec mon équipe sur l'expérience et les interfaces utilisateurs de nos produits.
[00:01:02] Et je suis Maëlle Gauthier, bonjour à tous. Je suis Product Manager chez Miracle depuis 2 ans et mon rôle c'est de développer des nouvelles solutions pour répondre aux besoins de nos clients.
[00:01:12] Et moi c'est Sabine Berland, je suis Product Content Manager chez Miracle également. Euh, product content, une discipline peut-être qui peut euh vous interpeller. Donc c'est tout ce qui concerne euh, le contenu relatif au produit. Donc, la documentation, on pense en priorité, l'aide en ligne, mais également euh la description des API, la revue de ces API et aussi les textes d'interface.
[00:01:35] interface. Je bloque sur le texte d'interface, on rentre un peu dans le vide du sujet directement. Donc laissez-moi revenir en quelques mots sur ce qu'est Miracle et quelle est son activité. Donc Miracle, c'est le cœur de la plupart des marketplace, donc on parle de commerce en ligne ici. Donc ce qu'on fournit, c'est une plateforme SaaS à nos clients pour permettre de développer un commerce en ligne. Donc d'onboarder assez facilement des vendeurs et puis euh bah du coup, on s'adresse dans le B2B et le B2C. B2C c'est peut-être plus facile euh à cerner. Je pense que vous avez tous expérimenté, c'est des clients comme vous, comme moi qui allons faire le shopping en ligne. On a par exemple comme client Maison du Monde, Carrefour, Decathlon, un peu partout en Europe, un peu partout dans le monde. Côté B2B, c'est des professionnels qu'on va mettre en relation les uns avec les autres. Par exemple, Coca-Cola ou Airbus. Les professionnels vont mettre en ligne sur la plateforme les pièces détachées pour alimenter les chaînes de production d'autres opérateurs.
[00:02:38] Donc Miracle c'est la techno, bien sûr, mais pas seulement. C'est aussi l'expertise et l'écosystème qui va avec et on accompagne nos clients dans leur transformation numérique. Ce sont de ce fait des milliers d'utilisateurs au quotidien, partout dans le monde, mais avec les milliers d'utilisateurs, on a un gros enjeu, ce sont aussi des millions de commandes à gérer au quotidien. Il faut pas que la plateforme plante et elle ne plante pas.
[00:03:05] Euh le la transformation numérique, c'est c'est vraiment quelque chose d'assez euh euh actuel. C'est en plein développement, en plein boom, je pense que vous n'êtes pas passés à côté. Et donc, pour nous, ça s'accompagne de challenges et d'une forte croissance. Miracle s'est donné les moyens, les d'atteindre ses ambitions, de pouvoir répondre au maximum à ses clients et euh et à tous leurs besoins. Et de ce fait, on a beaucoup beaucoup recruté ces derniers temps. Donc pour ma part, j'ai rejoint Miracle il y a 6 ans. On était 70 personnes. C'était une petite start-up. Tout allait bien. Tout va toujours bien, je vous rassure, mais aujourd'hui, c'est plus de 800 personnes, 800 collaborateurs de par le monde. Donc en 6 ans, on a connu une très très forte croissance et du coup ce sont plein de challenges qui s'accompagnent avec cette forte croissance. Donc nous avons le challenge d'onboarder tous nos nouveaux collaborateurs. Il faut qu'il puisse s'adapter à la culture de s'approprier la culture d'entreprise, s'adapter au process de l'entreprise, mais il faut effectivement aussi qu'il puisse euh bien comprendre le produit. Le produit est assez complexe de par sa richesse et sa flexibilité. On répond à beaucoup de cas d'utilisation. Et donc, il faut que nos consultants soient capables de comprendre le produit de A à Z, que notre département Labs, la R&D, soit également en mesure de comprendre tous les impacts et toutes les interactions qu'il y a entre chaque fonctionnalité.
[00:04:35] Donc, on a grandi très vite. Et effectivement, on va vous montrer euh, donc là je vous parlais d'un petit peu tous les collaborateurs. L'idée maintenant, c'est de zoomer sur l'équipe produit. Donc l'équipe produit.
[00:04:50] Attendez, pardon, je me suis trompée de côté. Hop! Voilà, l'équipe produit, elle aussi, elle a scalé énormément. Sur ces trois dernières années, elle a triplé. Et donc euh, elle triple et il faut pouvoir accompagner euh bah cette équipe qui grossit. On a été beaucoup en mode start-up jusqu'à présent. Les priorités étaient euh distribuées dans les équipes selon les affinités, les disponibilités des uns et des autres. On continue à travailler en mode agile, on mais par contre, on rythmait sur des road map trimestrielles. un peu un mode service desk qui permet d'aller très vite, c'est-à-dire celui qui est disponible va pouvoir être là pour répondre à au besoin de développement et du coup tout à chacun, on était assez polyvalent sur le produit. Et donc on pouvait euh, bah on avait un large scope fonctionnel finalement à maîtriser et à acquérir. Ça marche bien, ça nous a permis par exemple sur cette année de juste sur les trois premiers trimestres déjà de sortir plus de 170 fonctionnalités. Ça va bien, ça va vite, mais ça va même très vite.
[00:06:01] Et oui, et parfois, ça peut même aller un peu trop vite. Euh, donc cette euh, cette structure très agile où tout le monde intervenait euh à tout moment de du cycle de de développement produit. Euh, ben c'est ce qui nous a permis de de de croître. En fait, je suis pas du tout dans le bon sens.
[00:06:21] C'est dur les cliquer en fait.
[00:06:25] Hop là. C'est l'effet des mots, j'ai l'habitude. Hop là. Euh, donc effectivement, ça nous a permis en fait de d'avoir les les les succès qu'on a eu. Mais en fait, euh, ce ce mode qui nous permettait d'aller euh vite, euh faisait que parfois on voulait aller trop vite. Et euh ce cette structure avait quelques inconvénients qui sont devenus de plus en plus évidents au fur et à mesure que plus de collaborateurs nous rejoignaient et que notre spectre fonctionnel s'étendait. Donc pour vous donner quelques exemples de nos irritants, euh du côté de de l'équipe d'Anaïs au design, l'irritant principal, c'est que il y avait un manque de guideline concrète et partagé par tous. En fait, c'est principalement un un problème d'outils, le design system était un peu vieillissant, il comportait des des contraintes techniques. Donc il s'agissait de le mettre à jour. Par ailleurs, euh côté content, donc dans l'équipe de de de Sabine, l'irritant principal, c'était que on venait solliciter l'équipe content toujours en bout de ligne quand il s'agissait de nommer des concepts dans l'application. Donc ça veut dire que le content writer, il avait un temps très limité pour faire ses benchmarks, trouver le bon nom de feature, la bonne traduction et c'était en fait cette impression de toujours être en retard. Et enfin de mon côté, côté produit et tech, euh bah l'irritant, c'était que euh on changeait souvent de décision à la dernière minute et c'est jamais très agréable. Parce que euh parfois, en fait, pour éviter des incohérences, juste avant de de shipper la fonctionnalité, euh bah on allait euh défaire ce qu'on a fait pour le refaire et parfois, on allait retarder notre go live pour des petits détails. Mais en fait euh euh un un comportement qui va pas bien, euh un naming qui est pas compréhensible, c'est pas un petit détail parce qu'on peut le payer cher une fois que c'est en prod. Donc euh, tous ces petits irritants, ça veut dire que souvent on se retrouvait dans cette situation. C'est-à-dire, le rush. Euh c'est le bazar. Qui est-ce qui est dispo ? S'il vous plaît, help.
[00:08:37] Donc à ce à ce stade-là, euh notre enjeu, c'était euh de conserver notre agilité sans qu'elle devienne chaotique. En fait, on s'est rendu compte que que tous les petits cailloux qu'on avait dans nos chaussures en interne, ils pouvaient apporter des risques en externe et on voulait absolument les éviter. Le premier risque, c'était euh que notre produit perde en cohérence. On est de plus en plus à travailler sur des périmètres euh qui sont de plus en plus différents. Euh si euh on vient euh vendre une fonctionnalité euh à un client sous un terme, qu'on le documente d'une façon différente, qu'il est encore différent sur l'interface, on a perdu le client. Et en fait, euh, ça, ça Sabine l'a expliqué, notre logiciel, il est utilisé par des centaines de places de marché au quotidien, par des milliers de vendeurs. Euh s'il y a une incohérence sur, par exemple, importer son catalogue de produits, gérer une commande, ça peut vraiment impacter les revenus des vendeurs et nous indirectement. Et par ailleurs, ça pouvait potentiellement vraiment faire monter les coûts de support qu'on pouvait euh qu'on pouvait avoir. Donc à éviter. Et le deuxième risque potentiel qu'on avait identifié, c'est que euh bah on est euh beaucoup de gens à travailler sur beaucoup de projets mais finalement nos features sont pas forcément adoptées, peu ou pas adoptées parce que pas accessible. Euh, s'il y a des incohérences un peu partout et qu'il faut trois pages de documentation pour expliquer une fonctionnalité, bah c'est un fail pour l'expérience utilisateur. Nous ça nous coûte et euh c'est aussi un peu un cadeau empoisonné pour les équipes d'enablement. L'enablement chez Miracle, c'est euh les équipes de sales et de consulting qui sont euh en direct avec les clients pour faire adopter nos nos nouvelles fonctionnalités. Donc euh, à ce à ce stade-là, en fait, euh c'est c'est pas qu'on n'arrivait plus à travailler ensemble, c'était pas du tout le cas. C'était plus qu'au regard de notre taille, il fallait qu'on trouve la bonne structure, les bons process et surtout les bons outils pour gérer cette hypercroissance et arriver à parler d'une seule et même voix du moment où on vend la fonctionnalité jusqu'à ce que l'utilisateur euh l'utilise.
[00:10:52] Donc, on a commencé par se réorganiser. Euh, donc ce qu'on a fait, c'est sur euh tous nos différents produits, on est venu euh, je vous laisse le temps pour les photos. On est venu en fait, découper nos produits par domaine fonctionnel. Donc un exemple de domaine fonctionnel, la commande, le catalogue, euh le setup de la plateforme.
[00:11:13] Et on s'est organisé en squad. Donc une squad chez Miracle, c'est un product manager et euh une équipe tech. Et euh on est venu calquer ce mode de squad sur les équipes content et design. Donc comme vous le voyez sur le schéma, on a environ euh un designer et un content writer dédié pour trois squads.
[00:11:35] Euh et ça veut dire qu'on a toujours le même interlocuteur. Donc, on est passé du mode agence ou service desk dont Sabine parlait, à un mode One-One et euh on apprécie beaucoup ce mode. Premièrement parce que ça permet à tout le monde de développer une certaine expertise, euh d'aller en profondeur dans les concepts, d'avoir un peu des des automatismes au quotidien, mais aussi euh et là ça relève vraiment de l'agilité. C'est que vu qu'on travaille toujours toutes les mêmes personnes ensemble, on est en mesure de faire des rétros sur nos process, euh de euh de de vraiment développer nos routines de travail ensemble et c'est hyper appréciable. Et puis ça veut pas dire qu'en fait on est coincé là dans un domaine fonctionnel, il est carrément prévu dans nos parcours de carrière de si on veut changer de domaine, si on veut changer de squad, c'est tout à fait possible et euh tout tout est ouvert.
[00:12:28] Donc ça c'est pour pour la structure et on est aussi venu un petit peu retravailler euh nos process. Donc euh, on a mis à plat tout le process de création de produit qui est plutôt classique, on va du discovery jusqu'au delivery. Et euh et on a pris ce process et on est venu faire un raci. Alors je sais pas s'il y en a ici qui ont déjà fait l'exercice du raci. Ouais, c'est jamais une partie de plaisir, mais euh c'est vraiment un un un exercice qui est fastidieux mais absolument nécessaire parce qu'il permet vraiment d'avoir une matrice des rôles et des responsabilités de chacun à toutes les étapes. Et pour nous, dans une dans une phase où on était en train de recruter à fond, ça veut dire que n'importe quel collaborateur, même dès son premier jour, sait qu'est-ce qui est attendu d'il ou elle à quel moment du cycle de développement produit.
[00:13:22] Donc, je vais vous parler un petit peu de la façon dont notre trio Design Produit et Content travaille à chacune à chacune de ces étapes pour concrétiser un peu ça.
[00:13:32] Donc notre première étape, c'est euh le Discovery. Donc euh, à ce moment-là, le product manager va venir collecter tous les insights des clients pour définir la problématique qu'on cherche à résoudre. Et également, mettre en face la valeur business qu'on cherche à aller créer. Et ça, en général, on va faire un kick-off avec le design et le content pour euh bah s'aligner euh être d'accord sur voilà l'objectif ce qu'on ce qu'on cherche à résoudre. Et ce kickoff, c'est aussi un moment qui est très important pour que chacun puisse jauger l'étendue du chantier. Donc, côté design, à quels écrans on va venir toucher ? Est-ce qu'il y a des nouveaux écrans à développer ? Côté content, est-ce que on développe un tout nouvel usage, il faudra faire du benchmark ou c'est de l'amélioration de quelque chose d'existant et cetera et cetera. Donc très important cette phase pour se mettre un peu d'accord sur ce qu'on fait et a priori prévoir la charge de travail. La seconde étape, c'est la définition de solution. Donc en général, on va avoir plusieurs plusieurs solutions possibles. Et là, on réfléchit à des parcours sur l'interface utilisateur, mais également des parcours sur l'API. Donc pour les parcours sur l'interface utilisateur, l'équipe design va maquetter différents parcours. Et à ce stade-là, il y aura toujours une passe par un content writer sur euh les euh ce qu'on appelle les microcopies, donc tous les textes de l'interface. Et ça c'est assez chouette parce que ça nous permet de faire des tests utilisateurs où on va tester nos parcours, mais aussi la compréhension des concepts. Souvent c'est quelque chose qu'on qu'on avait qu'en bout de ligne, on se disait ah bah mince, l'utilisateur il comprend pas ce qu'on veut lui dire. Là, ça nous permet de de voir tout ça tout ça bien en amont.
[00:15:18] Sur les parcours par API, donc ça c'est plutôt le product manager et l'équipe tech qui vont les voir ensemble. Et on fera pareil, toujours une passe avec le content writer pour s'assurer que les labels des API, bah il y a pas de faute d'orthographe, que ça veut dire quelque chose et qu'on va pas faire d'overlap avec des concepts existants.
[00:15:36] Donc ça c'est pour euh c'est pour la phase de de définition. Et quand on est sur une fonctionnalité euh vraiment importante, c'est-à-dire qui va transformer des usages ou des fonctionnalités qu'on va venir monétiser, on peut à ce moment-là euh faire une passe aussi avec le product marketing. Pour s'assurer qu'on a un nom qui marche aussi bien en vente que dans l'interface utilisateur. Donc ça pareil, hyper important pour la cohérence de la vente jusqu'à l'utilisation. On passe maintenant à la phase de de développement, donc l'équipe tech est prête à coder ce qu'on veut faire. Et ce qui a été hyper structurant pour nous, c'est de se mettre d'accord sur une seule définition du Ready for Dev. La définition de c'est prêt à être développé, c'était à la base très différent en fait d'une équipe tech à l'autre, d'un PM à l'autre. Donc on a listé tout ça pour le clarifier. Je vais pas toute vous la faire. Mais ce qui est important de savoir, c'est que pour que ça puisse partir en dev, les maquettes sont terminées avec tous les cas nominaux et d'erreurs. Les labels, toutes les microcopies ont été validées par le content writer euh et tout est sur la maquette. Le développeur se base sur la maquette, il a pas plusieurs endroits de référence. Et par ailleurs, euh le designer va mettre à disposition du développeur ce qu'on appelle un développeur hand off euh, donc un fichier où voilà, il y a tous euh les paddings, les comportements détaillés, les espacements et ça ce qui nous permet de le faire, c'est notamment bah notre nouveau design système dont Anaïs va vous parler un peu plus tard.
[00:17:13] Et enfin, bah on arrive sur la phase de de delivery, euh la feature est codée, elle peut elle va bientôt pouvoir partir en prod. Donc on a un process qualité assez poussé chez Miracle, il y a plusieurs passes de code review, il y a de la quality insurance, donc de la QA. Euh mais il faut savoir que pour toutes les fonctionnalités qui touchent à l'interface utilisateur, il y aura systématiquement un PM accepta, mais aussi un designer accepta. Pareil, au moment de la QA et de la PM accepta.
[00:17:42] On va vérifier chacun chacune des microcopies. Donc c'est un peu le jeu des 7 erreurs pour s'assurer qu'il y a pas de typo, tout est OK. À cette étape-là, euh au produit, on a une euh euh on on a une phase de collaboration assez euh poussée avec l'équipe content pour aussi documenter la fonctionnalité. Donc le content writer va l'écrire, le PM va la revoir et un autre content writer va venir le valider pour s'assurer que c'est bien fait dans l'état de l'art. Et enfin, l'étape de delivery, on peut parfois faire des communications dans l'application et là encore notre notre trio bosse ensemble bah pour définir le message.
[00:18:21] Le visuel mais aussi programmer la communication. On a un calendrier partagé pour éviter que euh les quatre squads qui communiquent en même temps et que l'utilisateur soit bombardé de de nouveautés à tester dans l'application.
[00:18:36] Donc voilà un peu tout tout notre process et comment on on travaille ensemble. Bon, il manque un peu voilà les flèches parce que bien sûr, on réitère, on fait de l'amélioration continue.
[00:18:46] Mais vraiment de clarifier nos rôles et ce qu'il y a attendu chacun à chacune de ces étapes, c'est ce qui nous a permis de travailler un peu plus comme ça. C'est-à-dire en rythme et en équilibre. Et notre objectif, c'est que ce oulahoop euh il tombe le moins souvent possible.
[00:19:03] Donc voilà pour nos structures, nos process. Et on va vous expliquer un peu maintenant les outils qu'on a mis en place pour arriver à un peu mieux se se synchroniser à chacune de ces étapes.
[00:19:14] Bah, comme l'a dit euh Maëlle, le plus gros challenge c'était donc de parler d'une d'une seule et même voix.
[00:19:22] Et pour ça, on a commencé par la base. Il y a un an, on s'est relancé dans le redesign de toutes nos plateformes euh avec un nouveau design système 2.0. Ça faisait 10 ans que notre ancien design système, il était, notre produit était live et notre ancien design système il commençait à devenir un peu vieillissant, la gouvernance, elle était de plus en plus compliquée à gérer. Et donc naturellement, il y a une dette de design et une dette de front qui commençait à s'accumuler et donc il était temps de repartir sur des bases saines pour pérenniser le travail de de toutes les équipes. Ce nouveau design système, il avait pour but euh bah déjà de continuer à permettre au produit de à croître efficacement. En tout en gardant euh de la tout en apportant de la cohérence sur tous nos produits, retrouver des concepts UX qui sont similaires d'une plateforme à une autre. En tant que designer, ça nous permet aussi de nous focaliser beaucoup plus sur l'expertise et euh la recherche par exemple, les tâches à haute valeur ajoutée et moins sur le le craft des des maquettes, de ne plus avoir à toujours se poser les mêmes questions sur le type de composants à utiliser, la couleur des boutons et cetera. Et enfin euh le plus le plus gros avantage de ce nouveau design système, c'était de fournir euh à toutes les équipes un framework commun de travail pour qu'on puisse travailler efficacement et sereinement, avoir des patterns d'utilisation et des guidelines vraiment communes. à accroître efficacement. En tout en gardant de la tout en apportant de la cohérence sur tous nos produits, retrouver des concepts UX qui sont similaires d'une plateforme à une autre. En tant que designer, ça nous permet aussi de nous focaliser beaucoup plus sur l'expertise et la recherche par exemple, les tâches à haute valeur ajoutée et moins sur le le craft des des maquettes. Ne plus avoir à toujours se poser les mêmes questions sur le type de composant utilisé, la couleur des boutons et cetera. Et enfin, le plus le plus gros avantage de ce nouveau design système, c'était de fournir à toutes les équipes un framework commun de travail pour qu'on puisse travailler efficacement et sereinement, avoir des patterns d'utilisation et des guidelines vraiment communes.
[00:20:47] Ça a été faire un design system, c'est vraiment un travail d'équipe. Et c'était vraiment notre première étape de travailler ensemble. Les composants, les guidelines et cetera, elles ont été construites avec en collaboration avec l'équipe product design évidemment, mais aussi l'équipe front-end et l'équipe de Sabine, l'équipe content writer. Une fois que la machine de ce nouveau design system, elle a été lancée, ça nous a permis de passer à notre deuxième grande étape qui était de mettre la microcopie au cœur de l'expérience utilisateur. Donc comme vous l'a expliqué Sabine, la microcopie c'est les textes qu'on va retrouver sur les interfaces produits. Et chez Miracle, on a toujours été convaincu que de l'importance des mots et de l'importance de l'UX writing, mais l'ownership de sujet, il était pas toujours bien défini. Et souvent, ça arrivait en fin de parcours design et on remettait parfois en question les maquettes, les choix des composants qui ont été faits en amont. Donc concernant l'ownership, nous ça nous a paru évident que ce soit l'équipe content qui garde le sujet en main, mais du coup la question s'est posée de comment travailler mieux et plus efficacement entre product designer et product content. Déjà, ce qu'on peut constater c'est que ces deux métiers, ils se basent sur des expertises très similaires. Les deux équipes ont une connaissance très vaste des produits, de nos produits, parce que ce sont des équipes complètement transverse. Et là où le designer il va pouvoir faire de la user research, le content writer lui, il va pouvoir faire de la recherche terminologique. Là où le designer va s'occuper de l'ergonomie. Le content writer va pouvoir s'occuper de l'architecture de l'information et cetera et cetera. Du coup,
[00:22:31] l'idée c'était de vraiment de réintégrer le content à chaque étape. Donc là on voit le fameux process double diamant que vous vous connaissez sûrement. Et donc du coup de réintégrer le content à toutes les étapes du process design.
[00:22:50] L'idée c'est que on attend pas du designer qui il fournisse l'expérience finale à la première itération. C'est au fil de l'eau qu'il va que l'expérience va s'améliorer et qu'à la fin on a la parfaite expérience utilisateur. Et du coup, ça nous paraissait complètement normal que côté content, ce soit similaire. Jusqu'à maintenant, on demandait l'aide au content writer à la fin et on leur on leur disait bah voilà les maquettes sont prêtes. « Est-ce que tu peux m'aider à peut-être de nouvelles tournures de phrases et cetera ? » Alors que le content writer, il avait pas vraiment tout le contexte de la bah du du projet, de la feature et donc c'était compliqué.
[00:23:33] Une fois qu'on s'est dit bah c'est important de réintégrer le content à toutes les étapes, il a fallu qu'on réfléchisse aux outils qu'on allait utiliser. Naturellement, on s'est tourné vers Figma puisque c'était l'outil l'outil utilisé par les product designers sur lesquels on crée les maquettes. Et on a commencé par créer un template de de projet avec différentes pages et sections et l'idée c'était de pouvoir centraliser toutes les informations nécessaires depuis un même endroit. On a aussi défini nos nommaclatures de haut niveau des pages. pour que chaque produit, que que chaque équipe, que ce soit product ou dev, puisse s'y retrouver et connaître l'avancée du sujet.
[00:24:12] Ensuite, il a fallu accompagner l'équipe content dans la prise en main de l'outil. La prise en main de Figma, de notre design system, comment fonctionnent les composants, les override et cetera. Et chez Miracle, on utilise aussi la technique des slots.
[00:24:27] je sais pas si vous êtes familier avec ça, mais c'est une technique qui consiste à créer des slots dans des gros composants qu'on va venir après surcharger avec d'autres composants et qui nous permettent de de gagner du temps en itération, d'éviter à devoir détacher des composants et cetera. Et ça permet également au content writer de ça permet également au content writer de modifier d'éditer la microcopie à un seul endroit et que ça se répercute sur toutes les tous les écrans du projet. Du coup, vous avez compris, plusieurs personnes qui travaillent sur un même projet, ça peut être compliqué sur des mêmes écrans en même temps, ça peut vite devenir un peu un cauchemar. Et donc pour ça, on s'est mis à utiliser
[00:25:12] les branches de Figma.
[00:25:29] Ouh là, je vais le trouver. Non. Va dans les là. clique. Oh c'est mieux. Désolé.
[00:25:44] Les joies du direct de l'effet démo. C'est parfait.
[00:25:52] Hop, on va redescendre par là.
[00:26:04] Du coup, du coup, on s'est mis à utiliser les branches euh donc de Figma. Et euh comment comment on a utilisé ces branches ? Euh du coup le après le la phase de Discovery faite en trinôme entre PM Design et Content writer comme l'a expliqué Mathilde.
[00:26:24] Le designer va commencer à travailler sur des wireframe euh ou des écrans basse fidélité. Une fois qu'il a assez avancé dans son sujet, le content writer lui, il va pouvoir créer une branche dans laquelle il va commencer à éditer la microcopie. Et quand je dis éditer la microcopie, c'est pas uniquement euh remettre des S là où on en a oublié ou revoir la structure grammaticale. C'est aussi faire le travail en binôme avec le designer pour lui proposer une meilleure utilisation de certains composants. Par exemple, rajouter un help text au niveau d'un champ de formulaire qui serait potentiellement mal compris. Ou rajouter une petite bannière d'information pour certaines fonctionnalités un peu plus complexes à prendre en main.
[00:27:09] Une fois qu'il a commencé à travailler sur ça, on fait une première phase de validation, toujours à trois. Et on va merger les branches. Et ensuite, le designer va commencer, va pouvoir continuer à itérer, à aller sur des des mock-up un peu plus hi-fi. Encore une fois, le le content writer va pouvoir créer sa branche, remodifier un peu le contenu et cetera. pour qu'à la fin on merge, on fasse un final merge qui soit en gros une validation de l'expérience utilisateur au global, à la fois le parcours, à la fois la UI, mais aussi le contenu le contenu des maquettes.
[00:27:48] Du coup, il y a plusieurs avantages à faire intervenir le content writer le plus tôt possible dans le process. Déjà, ça lui permet à lui de comprendre la fonctionnalité dans son ensemble, d'avoir tout le contexte pour travailler au mieux sur la fonctionnalité et sur la microcopie. Ça permet au designer d'avoir très rapidement du contenu réel et pouvoir adapter la UI en conséquence en utilisant les bons composants pour le bon contenu et pas l'inverse. Et enfin, bah du coup, fini le faux texte dans les maquettes, on a directement du contenu intelligible euh qui va nous permettre de vraiment s'approprier la fonctionnalité et l'expérience et très rapidement on va pouvoir organiser des phases de test.
[00:28:33] Une fois toutes ces choses mises en place, naturellement, la question d'un content system en parallèle à notre design system est venue à nous et je laisse du coup Sabine vous en dire plus.
[00:28:47] Effectivement, donc vous l'aurez compris, le contenu est vraiment présent à tous les non, attends que vraiment présent dans dans le process de création du produit. Donc il est important de mettre en place finalement des références pour que on puisse alimenter les collaborateurs et qu'on arrête de se poser le genre de questions que vous avez pu voir en intro qu'Anaïs nous nous posait. Donc oui la microcopie ça a par exemple vous pouvez peut-être la connaître sous le nom de de label ou strings aussi dans dans dans certaines entreprises. Donc oui la microcopie ça a par exemple vous pouvez peut-être la connaître sous le nom de de label ou strings aussi dans dans dans certaines entreprises.
[00:29:14] Donc avant de pouvoir centraliser finalement le contenu et le design. Voilà le genre de situation auquel on pouvait se se retrouver confronté. Je vous laisse prendre connaissance des différentes modales.
[00:29:37] Et à votre avis qu'est-ce qui vous marque, qu'est-ce qui vous surprend, qu'est-ce qui vous vient à l'esprit ?
[00:29:48] C'est quelque chose de de satisfaisant ? Non, j'ai entendu des non quand même, c'est bien.
[00:29:56] Qu'est-ce qui va pas ? Qu'est-ce qui pose problème ?
[00:30:01] Effectivement, on s'entend, on a des différences de couleur. On a du rouge sur le bouton d'action principal, on a du bleu. On a des différences de de taille, on a des différences de wording aussi, donc les mots. Quand on rentre dans le détail, donc aussi rien qu'au niveau des titres, on voit une différence de ponctuation. Quand on rentre dans le détail du help text, on voit qu'on a différents termes. Là aussi, donc des termes, c'est pas forcément un concept hyper du jargon quoi. Ça peut être par exemple, bah la différence entre, si ça marche, changes, edits.
[00:30:29] changes, edits de de quoi on parle exactement ? Et au final, en fait, qu'est-ce qu'on veut faire passer comme message à l'utilisateur ici ? Bah ça c'est simple, on veut lui dire que attention, tu as pas sauvegardé tes tes modifications, tu risques de les perdre. Bah ça c'est simple, on veut lui dire que attention, tu as pas sauvegardé tes tes modifications, tu risques de les perdre.
[00:30:44] Donc le message il est clair, il est simple, il est unique. Simplement, on a quatre façons de le dire différentes là. Donc on pourrait se dire, bah, c'est pas grave, le le client, l'utilisateur va pas le voir, c'est sur différentes pages à chaque fois. Oui, bien sûr, il verra pas tout d'un coup comme ça, on là on les a mis à plat exprès bien sûr. Simplement, et bien ça a un impact aussi business, l'air de rien. Donc ça a un impact côté utilisateur, finalement. parce que bon, quand on voit un bouton rouge, on quand même, on y réfléchit à deux fois avant de cliquer dessus. Est-ce que dans ce cas-là, il faut qu'il soit rouge ou il faut qu'il soit bleu ? Et puis côté business, en fait, c'est que l'interface de Miracle, c'est 24 langues. Et puis côté business, en fait, c'est que l'interface de Miracle, c'est 24 langues. On l'a traduit dans 24 langues.
[00:31:24] Donc juste, ces quatre petits mots, ces quatre petits textes, c'est déjà 280 € de traduction. C'est pas grand-chose. OK, on en parle de quatre là. On a 10000 microcopies dans l'interface. Je vous laisse faire le calcul.
[00:31:43] Donc bien sûr, le content system s'est imposé à nous pour limiter ces coûts inutiles pour l'entreprise et c'est là où en fait, on va venir en complément du design system. un add-on, finalement, au design system pour expliquer comment utiliser tel ou tel texte. Quel pattern. On a des patterns qui se définissent assez facilement, on le voyait précédemment quand même. Euh mais on va pouvoir euh tout centraliser en un seul et même endroit et euh accompagner chaque composant du design avec des recommandations sur le contenu. Donc on vient en complément du design system parce que en fait ce qu'on veut c'est avoir une seule et unique source de vérité. Donc on vient en complément du design system parce que en fait ce qu'on veut c'est avoir une seule et unique source de vérité. qu'on arrête de se poser ces questions partout et et puis euh bah qu'on ait tout en un seul et même endroit, que ce soit facile, utilisable aussi pour nos collaborateurs. Une espèce de single spot où tout le monde va trouver les réponses à ces petites questions qu'on n'aime pas forcément se poser et qui sont récurrentes en général. Une référence, c'est pratique, ça met fin à beaucoup de discussions très rapidement en général. Et ça va permettre aussi de rendre plus autonome bah nos content writer, plus efficace, autonome aussi les designers et les product managers parce que bon, on parle de fonctionnalités, mais toutes les fonctionnalités ne passent pas nécessairement par la phase de Discovery. On va si on a besoin de rajouter une modale ou de compléter une fonctionnalité qui est déjà bien en place. on a pas forcément besoin de faire toute la grosse recherche du Discovery pour pour développer le contenu et pour autant il faut qu'on aille vite et il faut le faire. Ça reste indispensable pour l'expérience client. Donc, pour rappel, le design system, bon, je pense que vous connaissez à peu près tous, vous avez compris le le principe, hein. Donc, pour rappel, le design system, bon, je pense que vous connaissez à peu près tous, vous avez compris le le principe, hein. Donc on a une librairie avec des composants qu'on va retrouver dans l'interface.
[00:33:28] On va retrouver les guidelines sur comment utiliser ces composants. Quelle marge, quel padding, quel pixel, quelle taille et cetera et le langage visuel, quelles icônes, quelles illustrations mettre en place. Côté content system, on vous parlait de de compétences similaires déjà tout à l'heure. Là, on s'y retrouve aussi. Côté content system, et ben, finalement, on va retrouver pareil. Côté content system, et ben, finalement, on va retrouver pareil, une librairie avec toutes les chaînes de microcopie du produit et des guidelines qui expliquent comment la rédiger.
[00:34:00] Donc ça nous permet aussi euh de bah d'anticiper ce genre de question qu'on pouvait avoir tout à l'heure où euh comme le l'expliquait Mathilde, on a une API qui est développée, puis finalement dans l'interface utilisateur, c'est encore autre chose. Donc pour la facilité de de prise en main du produit, c'est pas c'est pas l'idéal.
[00:34:19] Ça permet également de se concentrer sur des tâches à plus forte valeur ajoutée pour chaque rôle, chaque discipline.
[00:34:29] Donc la théorie c'est bien jolie, mais comment ça se passe concrètement ? Euh donc je vais vous faire un petit focus sur Zeroheight. Donc Zeroheight c'est un c'est un système qui permet de créer des collections de composants et de normes qui s'intègre avec des design systèmes assez enfin des des outils de design pardon. Et euh et donc en fait, c'est sur Zeroheight qu'on a basé notre design system. Et en fait, c'est sur Zeroheight qu'on a basé notre design system. Donc tout naturellement, c'est dans Zeroheight qu'on a rajouté les informations sur le contenu. Ce qui fait que maintenant quand on arrive dans Zeroheight, on a la liste de nos composants.
[00:34:58] la façon de les utiliser dans le design et une partie contenu, comment ça fonctionne.
[00:35:07] Je vais faire un petit focus vite fait sur l'illustration en fait que vous avez là pour vraiment rendre la chose très concrète. On voit qu'on a euh bon, on voit, essayez de voir, c'est une page vide, c'est l'empty state.
[00:35:16] on voit, essayez de voir, c'est une page vide, c'est l'empty state. La fameuse page vide. La page vide, personne n'aime ça dans un produit logiciel. Une page vide c'est un fail où il y a quelque chose qui se passe pas, c'est un produit non utilisé. Donc on en veut pas de la page vide. L'idée c'est de d'inciter l'utilisateur à la remplir. Parfois l'utilisateur il y est pour rien, il y a la page est vide parce qu'il a pas encore du contenu pour remplir cette page. Par exemple, si on prend notre vendeur, qu'il a pas encore créé de commande, qu'il a pas encore reçu de commande, ce sera vide. L'idée c'est de pouvoir le rassurer. Qu'il panique pas, qu'il continue son flux de travail normal et donc on aura un petit help text qui dira bon bah ce sera rempli dès que vous aurez des données, tout va bien. Jusque là so good. Par contre, on arrive à avoir des pages vides parce que l'utilisateur n'a pas effectué toute la configuration du produit, il ne l'exploite pas dans son entièreté. Et dans ce cas-là, et bien en fait euh je vous montrais tout à l'heure à plat les les différentes modales, on a analysé aussi côté contenu toutes euh les situations, les cas d'utilisation possibles de dans quelle situation on peut se retrouver sur cette page vide. Donc quand on s'aperçoit que la page est vide parce qu'il manque une configuration de la part de l'utilisateur. Donc quand on s'aperçoit que la page est vide parce qu'il manque une configuration de la part de l'utilisateur. L'idée va être de lui mettre un petit texte pour lui dire oui, c'est vide pour l'instant parce que tu n'as pas encore configuré telle ou telle chose. Et derrière, côté design, on se complète en mettant un bouton de call to action. Configure et rempli ta page. L'avantage d'avoir tous ces toutes ces informations, me direz-vous dans dans une page vide, et bien ça va derrière faire gagner en efficacité l'utilisateur. Il va éviter de briser son flow de travail. en allant chercher le consultant qui lui a vendu le produit, ouais, ça marche pas, votre page est vide, ou alors en allant rechercher, j'espère, de temps en temps, dans les dents lignes.
[00:37:00] Pourquoi ça marche pas ? Ou encore pire, interrompre son collègue d'à côté dans son travail, dans son flux de travail, dans sa tâche quotidienne. dire eh eh, explique-moi pourquoi c'est vide. Non, on veut pas interrompre l'utilisateur, donc on lui met l'info dont il a besoin, quand il en a besoin, où il en a besoin. Non, on veut pas interrompre l'utilisateur, donc on lui met l'info dont il a besoin, quand il en a besoin, où il en a besoin. Dans le content system, on va donc retrouver ces règles rédactionnelles donc par composant, grammaire typographie pour éviter de savoir s'il y a besoin de point d'interrogation ou pas dans les titres. Euh le glossaire, quand on a vraiment un gros concept nouveau à documenter, l'avoir dès le début de la création du produit, ça permet d'aligner effectivement toutes les équipes, ce qu'on vous disait tout à l'heure, au moins on parle d'une seule et même voix en interne. au moins on parle d'une seule et même voix en interne et donc le concept est ancré dès le départ dans l'esprit de tous les collaborateurs. Et on a enfin des principes d'UX writing.
[00:37:47] Donc l'UX writing, bah ça va être typique, ces petites astuces, qu'est-ce qu'on dit à l'utilisateur sur cette page vide ? L'UX writing, c'est pratique aussi parce que ça va nous déplacer un problème qu'on peut avoir de temps en temps. L'UX writing, c'est pratique aussi parce que ça va nous déplacer un problème qu'on peut avoir de temps en temps, c'est-à-dire que si on ne met pas ce help text, cette bonne pratique finalement du UX writing de donner un peu plus d'informations et de contexte à l'utilisateur, on a souvent tendance à stacker tout dans un bouton. Le fameux call to action, on va le remplir, il va être super énorme, ou alors on va vouloir en mettre un maximum. Donc ça marche bien en anglais ça, mais quand vous traduisez dans 24 langues. Donc ça marche bien en anglais ça, mais quand vous traduisez dans 24 langues, faut savoir qu'il y a des langues qui ont un coefficient de foisonnement assez important. Coefficient de foisonnement, c'est la la longueur du texte dans dans la langue cible. Et du coup, par exemple, bah ça vous évite d'avoir votre design tout pété parce que le traducteur allemand est passé par là et que ça tient plus dans la case.
[00:38:42] Donc, je vous parle aussi un peu de traduction parce que l'idée c'est d'aller plus loin pour nous aussi. Donc c'est encore une réflexion en cours, enfin c'est plus qu'une réflexion parce qu'on a déjà des bonnes maquettes et qu'on est en train de l'implémenter. Pour l'instant on a pas encore les résultats sur ce point là. mais pour aller plus loin, on voulait donc mettre toutes les chaînes de microcopie, la librairie du content system à disposition de nos collaborateurs. C'est-à-dire, on a regardé un peu partout sur le marché, on a pas trouvé d'outils qui répondaient à notre besoin. C'est-à-dire, on a regardé un peu partout sur le marché, on a pas trouvé d'outils qui répondaient à notre besoin. Donc on va créer notre propre CMS, c'est-à-dire un espèce de enfin pas un espèce de, non non, tout à fait, un répertoire central avec toutes les chaînes de la microcopie en anglais. Donc la microcopie, elle est importante pour pour les développements par exemple, parce qu'on va avoir le développeur va avoir besoin de la clé pour appeler le texte. Donc la microcopie, elle est importante pour pour les développements par exemple, parce qu'on va avoir le développeur va avoir besoin de la clé pour appeler le texte. Mais en fait, c'est tout ce dont il a besoin. Après, on met le texte qu'on veut, il s'en fiche, du moment qu'il a sa clé, c'est bon. Donc l'idée, c'est d'avoir dans ce répertoire, la clé de la microcopie.
[00:39:37] La valeur en anglais et pour aller plus loin, ce à quoi on travaille actuellement, les traductions qui sont associées. Comme ça, on va permettre euh de euh au product manager, au content designer d'être encore plus autonome sur des fonctionnalités qui n'auraient pas besoin de Discovery, sur des fonctionnalités un peu plus tricky qui vont vouloir euh tester, peut-être avec des clients pas forcément anglophones. Donc on va pouvoir récupérer le contenu facilement. Et donc ce ce répertoire, on le met à disposition vraiment de tous les collaborateurs, que ce soit tech et produits.
[00:40:11] Ehm, voilà. Je pense que j'ai fait le tour de des outils. Euh ça marche bien. Donc je vous disais depuis le début de l'année, on a livré plus de 170 fonctionnalités. Et euh mais bon, c'est c'est quand même un gros travail.
[00:40:28] Effectivement, c'est c'est un gros investissement euh qu'on a qu'on a mis en place depuis un an. Euh c'était pas simple. Ça nous a demandé du temps, euh d'itération et cetera, mais euh c'est c'est vraiment euh c'est vraiment l'investissement qui va nous permettre en fait de de soutenir la croissance du produit. c'est vraiment l'investissement qui va nous permettre en fait de de soutenir la croissance du produit et de les exposer au au au futur challenge. Il y a eu un accompagnement du changement auprès de toutes les équipes. Il y a eu un accompagnement du changement auprès de toutes les équipes. Avec beaucoup de communication, du coaching, on a aussi systématisé le process dans on les on l'a documenté à différents endroits pour que on ait une une référence commune. Et évidemment, c'est une démarche qui est complètement itérative. Donc régulièrement, on récupère les les retours des équipes, on fait des rétrospectives, on se repose la question de est-ce que ça fonctionne et on a surtout pas peur de se dire bah finalement peut-être que cette petite idée, elle fonctionne pas, on on la remet à plat et puis on repart sur quelque chose de nouveau.
[00:41:32] Voilà euh pour nous. J'espère que ça vous aura donné des billes pour potentiellement faire la même chose de votre côté euh ou vous aider avec vos vos problématiques propres.

Transcription