Transcription de l'épisode : "Maud Laville, Mettre en place un design system dans un contexte de rebranding"
Terry : Salut Maud.
Maud : Salut Terry.
Terry : Merci de prendre du temps aujourd'hui pour parler de design system, design system dans un contexte de rebranding. Donc ça va être la thématique de notre échange et avant de rentrer dans le vif du sujet, je te propose de te présenter et puis de présenter ce que tu fais chez Brevo.
Maud : Je suis Maud, lead design system chez Brevo. Je suis product designer essentiellement. Je lead l'équipe design system de Brevo depuis juillet 2022, quasiment un an et demi. Brevo, c'est un produit qui permet à des business, à des entreprises, plutôt petites entreprises, moyennes entreprises, de scaler leur business et de développer leur activité autour de la relation client. Et donc en gros le produit Brevo va proposer plein d'outils pour permettre de construire une relation client et d'améliorer sa relation client. Donc initialement Brevo c'est Saniglou qui a donc subi un rebonding. pour devenir Brevo. Et donc, initialement, on est sur des campagnes e-mail, SMS, WhatsApp, des notifications, de l'automatisation. Il y a des outils aussi autour du CRM, des pipelines de vente, la gestion de rendez-vous, la téléphonie, des liens de paiement. Il y a vraiment un panel d'outils pour permettre aux utilisateurs d'augmenter leur business.
Terry : Très clair, du coup pour bien que les gens comprennent aussi la taille de votre équipe, de Brivaux, donc anciennement Sembling Blue, au global et du coup en quoi après ça pose de gros enjeux quand tu fais un rebranding comme ça, comme cela. C'est quoi à peu près l'effectif à la louche qu'il y a chez Brivaux et côté design et product and tech ?
Maud : Alors Brevo, c'est une entreprise de... je crois qu'on a passé les 800 personnes, donc c'est 800 personnes à travers le monde. Les équipes tech, on a à peu près 50 frontes. Je ne sais pas combien il y a de bacs et je ne suis pas sûre de vouloir le savoir, mais en tout cas voilà. Et l'équipe produit, c'est à peu près 50 personnes. Et au sein de l'équipe produit, moi je suis spécifiquement dans l'équipe design, donc l'UX team chez Brevo, qui est à peu près composée de 25 personnes, avec les product design évidemment, la content team, la design system team et l'UX research team.
Terry : Ok, très clair. Donc là, ça pose un peu le décor, on voit que ce n'est pas des petites équipes, et donc ça fait une taille importante derrière pour gérer tout ça. D'où l'intérêt aussi de mettre en place un design system pour permettre d'homogénéiser derrière tout ce qui va être expérience utilisateur, design, la partie purement UI, et puis après aussi communication auprès des clients. Tout à fait. Donc quand tu es arrivé, c'était encore SendingBlue, le rebranding avait déjà commencé ?
Maud : Quand je suis arrivée, c'était encore Standing Blue, le rebonding était clairement programmé, ça n'arrive pas comme un cheveu sur la soupe, donc c'était prévu et j'ai été embauchée aussi pour ça. pour préparer ce rebranding et pour aussi accompagner. Souvent, dans un rebranding, on va refaire le site public, le flagship website, et donc en fait, le produit, très souvent, ce n'est pas si fréquent qu'on rebrande le produit en même temps. Là, il y a un renaming en même temps, puisqu'on passe de Sanim Blue à Brevo, et donc il y avait un vrai besoin de complètement switch d'identité à un jour précis. C'est pour ça que j'ai été en partie embauchée aussi pour préparer tout ça.
Terry : Donc première question assez large mais toi quand t'arrives du coup qu'on te pose ça comme mission c'est quoi un peu ta démarche pour te dire comment je vais attraper ce problème, par quel bout je vais le prendre, quelles questions tu t'es posées et quelles étapes tu t'es définies ?
Maud : La première étape, de toute façon, ça a été de voir l'existant, d'auditer, d'analyser l'existant, puisque ma deuxième mission, en fait, c'était quand même de m'occuper du design system et de gérer le design system de Seine-et-Glou à l'époque. Donc il y a eu une grosse phase d'audit et en parallèle de ça, on a commencé à se mettre d'accord aussi avec les équipes marketing et donc les équipes de brand. C'était hyper essentiel parce qu'en fait, un produit ne répond pas aux mêmes besoins pour les utilisateurs qu'un site public. On a des contraintes bien plus grosses, notamment dues au legacy. À la sémantique aussi, qui n'a pas du tout la même signification. Le vert dans un produit, ça a des significations très particulières. Le rouge, ça a des significations très particulières. Le orange... Donc en fait, quand on construit une identité, il faut quand même faire attention à tout ça et à l'existant.
Terry : Oui, donc pour bien comprendre quand tu dis l'inertie du Legacy, ou en tout cas un peu la complexité du Legacy, c'est qu'en fait tu as des utilisateurs qui ont une habitude sur l'usage du produit tel qu'il est, et pas sur la partie visible marketing, on va dire inbound, mais vraiment sur une fois que tu as converti que tu as vraiment tes utilisateurs qui utilisent le produit au quotidien. Et eux, on l'a tous vécu sur certains produits. Un des plus connus pour le public français, la majorité du public sur le podcast, c'est l'application SNCF Connect, qui a fait beaucoup parler quand on est passé de l'ancienne à la nouvelle, parce que l'usage a complètement changé. Et donc si on n'accompagne pas l'utilisateur.
Maud : À ce niveau-là, C'est exactement ça. Ce qui n'a pas très bien fonctionné pour OUIS-NCF, c'est le changement complet et le manque d'accompagnement, au-delà des changements visuels et du changement de nom. Je me demande s'il n'y avait pas un changement de nom avec OUIS-NCF. Ça, je veux dire, c'est pas très grave pour les utilisateurs qui sont déjà dans le produit. Ce qui va être grave, c'est de changer complètement les choses et de les déboussoler, en fait. C'est ça qu'on cherche à éviter.
Terry : Donc là, grosse compréhension, on travaille pour savoir comment ça fonctionne sur l'existant. En même temps, j'imagine que tu réfléchissais pour la mise en place en parallèle de ce design system. Après, une fois que tu as pu créer une compréhension de ce qui existait, quelles ont été les prochaines étapes ? Parce qu'on parle de design system, peut-être tu peux donner, pas spécialement une définition, mais l'intérêt du design system pour Brevo. et aussi que tout le monde puisse mesurer les challenges qu'il peut y avoir aussi sur la partie adoption de ce type de cadre de travail, de framework pour les équipes qui ont une habitude de travail actuelle et qu'il va falloir aussi faire changer en interne.
Maud : Quand je suis arrivée et qu'on a audité la partie design, le design system était plutôt bien adopté. Il y avait des problèmes très pratiques, des cas pratiques sur des composants très particuliers, sur des patterns très particuliers. Ça, c'était la partie facile. La partie un peu plus compliquée, c'est l'adoption au niveau des techs. Et en fait, un design system, il a de sens que s'il est adopté à la fois par les designers et à la fois par les développeurs. Le but d'un design system étant quand même de faire gagner du temps à tout le monde, tout en permettant d'avoir une expérience cohérente pour nos utilisateurs. Et le but aussi ultime, c'est que les gens se concentrent, c'est-à-dire mes utilisateurs premiers, les développeurs et les designers, se concentrent à designer et pas à se poser des questions et à réinventer la roue à chaque fois qu'il y a un nouveau bouton à créer ou ce genre de choses. Donc c'est aussi évacuer la partie un peu basique, même si c'est loin d'être basique de créer un design system, on veut évacuer tous ces sujets pour nos designers et nos développeurs aussi. Quand on sait qu'il va y avoir un switch important, et qu'on sait aussi que le design system n'est pas adopté au niveau tech, la première chose à faire, en parallèle de mettre en place la brande, et rebrander à proprement parler, et de passer de Sanimloo qui était une identité bleue, à Brevo qui est une identité verte, Globalement, ça, c'est la partie facile du rebranding. La partie compliquée, ça va être l'adoption et comment convaincre à la fois les designers, à la fois les développeurs, à la fois les product managers aussi de prévoir du temps, de planifier ses tâches qui sont de migrer d'une ancienne librairie de composants React à la librairie du design system.
Terry : Et donc là-dessus, sur ce travail un peu d'évangélisation pour l'adoption, c'était quoi un peu toi tes techniques ou en tout cas le retour que tu en as aujourd'hui avec le recul sur ce qui a bien marché, est-ce que tu aurais peut-être fait différemment les choses, un peu les tips pour des personnes qui seraient dans des situations similaires ?
Maud : Je pense qu'il y a une... Alors ça c'est globalement, c'est pour toutes les missions de personnes qui font du design system, ou de l'obs je dirais, c'est globalement beaucoup de communication, d'expliquer ce qui peut paraître complètement évident pour soi, ça l'est pas du tout pour les autres, et donc la première partie ça a été l'évangélisation de c'est quoi un token, c'est quoi un composant, c'est quoi un pattern, Comment on va rebrander ? Ça c'était une grosse inquiétude pour tout le monde. Qui doit rebrander ? Comment on a prévu de rebrander ? Est-ce qu'on fait tout d'un coup et du coup c'est une très grosse charge de travail ? Ou comment est-ce qu'on prévoit les choses et comment est-ce qu'on va planifier et créer finalement une sorte de roadmap parallèle pour... Malgré tout, produire à la fois des features, sortir des features, délivrer, et en même temps prévoir ce rebonding qui arrive à une date très précise.
Terry : Oui, parce que là-dessus, ce qui peut être compliqué dans le cadre de l'adoption, comme tu viens de le dire, c'est que tu as des équipes qui sont en place, qui ont déjà des choses à délivrer sur l'existant, pour l'utilisateur actuel, et en même temps, on leur rajoute, entre guillemets, une charge de travail qui leur fera gagner du temps dans le futur, mais très court terme, ils sont là, on est déjà sous l'eau, comment on fait pour réussir ? Ce n'est pas un sujet qui est hyper évident là-dessus.
Maud : Et en fait, c'est là où le product management a de l'intérêt, c'est de planifier ces tâches-là. Et c'est valable pas uniquement pour un rebranding, c'est valable aussi quand on migre et qu'il y a un nouveau composant. Je pense aux composants très compliqués comme les dates à table ou ce genre de choses. Ça arrive qu'en fait des fois il faille prendre le temps de passer et de migrer sur un composant design system qui a été pensé, qui est probablement plus utilisable pour les utilisateurs et plus scalable aussi.
Terry : Très très clair, toujours pour rester un petit peu sur la partie tech du design system, quels sont les aspects toi où tu as vu le plus de bénéfices pour les techs ou peut-être des retours à postériori de choses, ah ouais franchement là c'est top maintenant on gagne un temps fou, peut-être auxquels tu t'y attendais pas ou en tout cas des bonnes surprises sur certains composants en particulier ou certaines choses.
Maud : Alors globalement, en fait, la très bonne surprise, c'est que maintenant, les techs, avant de créer un nouveau composant, ils vont venir voir le design system en disant, vous ne voulez pas nous créer le composant ? Ce qui est du coup l'écueil inverse et ce qui nous amènera à la contribution, je pense. Mais ça, c'est une marque de confiance énorme pour nous. Il y a eu ça et il y a eu aussi pendant la migration qui a duré quand même 4 mois, enfin genre c'est assez long quoi. Progressivement on a migré des pages, on a mis en place un tamer pour pouvoir quand même rester sur Sendiblue et en même temps designer pour Brevo. Donc côté dev et côté design. Et donc en fait très progressivement on a mis, enfin avant tout ça on a mis en place un tracker. pour savoir combien de composants du design system étaient dans les codes base, combien de composants de l'ancienne librairie étaient encore dans les codes base, et là on a vu le ratio s'inverser de façon assez exponentielle, et sur tous les composants en fait. Il n'y avait pas spécifiquement de composants un peu à la traîne. Les composants à la traîne, c'est toujours les plus gros composants qui constituent quasiment une page. Les datatables, les listes, les cambans, ce genre de gros composants qui parfois nécessitent aussi une refonte du bac et de comment ça fonctionne derrière.
Terry : Et c'est hyper intéressant l'aspect tracker là, c'est-à-dire qu'en fait, vu que vous aviez déjà un existant, c'était de pouvoir aussi, toujours l'importance de pouvoir mesurer quand tu fais des changements comme ça, un peu là où t'en es, et si c'est un succès ou pas, et du coup mettre en place sur l'existant pour ensuite voir comment ça évolue de l'ancien vers le nouveau. Je trouve que c'est un point assez intéressant. Vous aviez la chance aussi là d'avoir déjà un dizaine de systèmes plus ou moins existants pour pouvoir faire ça.
Maud : — Oui, clairement, le design system, il préexistait, ça c'est sûr. Il y avait d'anciennes librairies de composants qui n'étaient pas un design system. Un design system, ce n'est pas juste une librairie de composants. Petit rappel.
Terry : — Ça me fait penser, si tu peux un peu détailler du coup, la complexité de ce que c'est qu'un design system.
Maud : Alors un design system, c'est... On travaille quand même sur de l'atomique design, donc on travaille avec des tokens qui sont les plus petites parties du design system. Ça va être une couleur, un dégradé, un border radius, un spacing. Voilà, ça c'est les tokens. Ensuite, à partir de ces tokens, on crée des composants. Simple, on va dire ça comme ça. Et donc ça, ça va utiliser les tokens pour créer un bouton, par exemple. À partir de là, on va évidemment ne pas s'arrêter à des petits composants simples et efficaces, malgré tout. On va créer des composants plus complexes. On va nester, donc mettre à l'intérieur d'autres composants. Et puis à la fin, on a aussi les patterns, c'est-à-dire comment fonctionne un composant, à quel moment on doit utiliser ce composant-là plutôt qu'un autre. Pour tout ça, dans le but évidemment de créer une expérience coréente pour nos utilisateurs. Ça permet aussi de voir le produit comme quelque chose d'holistique. d'avoir une vision un peu plus big picture de la chose, ce qui est un peu un écueil aussi pour les product designers qui vont souvent être sur une partie du produit, c'est la même chose pour les PM, c'est la même chose pour les techs, chacun est dans sa partie du produit et donc très vite en fait on arrive à des petits comportements très spécifiques à chaque produit. le design system il permet de prendre un peu de recul et de dire ah bah attends bidule il le fait comme ça et truc il le fait comme ça peut-être qu'en fait vous pouvez faire la même chose voilà ça ça fait partie c'est les coulisses du design system c'est pas que la librairie de composants c'est surtout en fait les discussions qui vont permettre de dire attends il y a peut-être un moyen de faire en sorte que l'utilisateur à la fin il est la même expérience pour potentiellement.
Terry : La même chose quoi Oui, c'est ça qui est complexe quand tu as beaucoup de vues différentes, de types d'interactions différentes, c'est-à-dire de réussir à avoir une homogénéité de comment ton application se comporte sur toutes les fonctionnalités qui existent, parce que comme tu le dis, ces fonctionnalités-là vont être dédiées à certaines équipes, certaines squads qui vont être concentrées uniquement sur un aspect du produit. Et il faut prendre du recul pour avoir la vision globale et se dire est-ce que là, le type de comportement de ma modal view, peu importe, est le même sur l'ensemble du périmètre du produit. Et donc sur un gros produit tel que Brevo, on peut comprendre rapidement à quel point c'est complexe et en même temps hyper important d'avoir ces comportements homogénéisés.
Maud : Oui, tout à fait.
Terry : Hyper clair, ça me permet de faire la transition vers la partie content aussi, dont tu as touché du doigt au début, c'est-à-dire que tu disais les landing pages, les pages purement en marketing qui vont permettre de récupérer les clients de manière inbound, qui vont ensuite potentiellement se convertir et venir utiliser le produit. Eux, ils ont peut-être plus de flexibilité dans le contexte du rebranding, on va dire, de changer les verbatims, la façon dont ils s'expriment sur la nouvelle façon dont la marque veut s'exprimer. En revanche, sur les utilisateurs existants, si tu commences à complètement changer la façon dont tu t'exprimes, ça peut créer beaucoup de friction et en même temps, si tu le fais pas, les nouveaux qui vont arriver dans un type de verbatim, ils vont se retrouver derrière à utiliser une application qui ne parle pas du tout de la même manière que sur la page purement marketing. Donc comment un peu t'as géré ça ? Comment vous avez géré ça ? Parce que je sais que t'avais une équipe aussi Content, si je dis pas de bêtises.
Maud : Ouais, il y a l'équipe Content qui travaille avec nous, il y a des équipes Content côté marketing, des PMM, voilà, qui vont évidemment travailler ensemble, enfin, qui travaillent ensemble. Un rebranding c'est aussi changer de ton, c'est aussi changer de... alors on n'a pas vraiment changé de valeur mais on change quand même... enfin on fait pas un rebranding pour le plaisir. Il y a derrière une stratégie marketing, il y a évidemment... un ton différent, un positionnement différent potentiellement, et donc il faut retravailler ça. Ça va forcément atterrir d'une certaine façon dans le produit. Moi j'avoue que je ne me suis pas vraiment occupée de la partie website. Je sais que par contre c'est des questions qui ont été posées au niveau du contenu. Et côté UX, les équipes content, ce qui est hyper intéressant, c'est le moment où on va rajouter cette sous-couche content dans le design system et où au final on vient aussi systématiser la façon dont on s'adresse à nos utilisateurs. Et donc là c'est ce qu'on est en train de mettre en place. Ça c'est très très long pour plein de raisons, c'est qu'en fait tant qu'un pattern n'est pas méga bien défini, que le ton est pas méga défini non plus, ça prend beaucoup de temps de définir le ton, d'être juste, de bien savoir ce qu'on veut dire à nos utilisateurs.
Terry : Ça comment déjà vous travaillez sur cette définition du ton ? Est-ce que, alors après peut-être c'est plus les équipes content, mais si tu peux en parler un petit peu de ce que tu vois, de comment c'est cet aspect-là ?
Maud : Il y a en fait, ce qu'il faut comprendre sur le content en termes d'UX, c'est qu'il y a forcément une façon de s'adresser aux utilisateurs en termes de brand et donc là, Ça, c'est vraiment vu avec le marketing. Voilà, de rester humble, de rester beginner first, donc de s'adresser quand même à des experts, mais aussi à des gens qui débutent le marketing et le développement de leurs relations clients. Et côté UX, t'as aussi forcément le besoin d'exprimer les choses très clairement, de décrire les choses très clairement. T'as des patterns, des web patterns en fait aussi qu'il faut prendre en compte, c'est-à-dire qu'on va pas réinventer le bouton cancel. Même si tout ceci est discutable et ça dépend aussi de ce qu'on se dit. Mais voilà, une erreur, c'est quoi une erreur ? C'est spécifique en fait. Il faut définir quelle est l'erreur, expliquer ce que c'est, et puis donner une porte de sortie par exemple. Et donner la porte de sortie, ça peut faire partie du design system.
Terry : — Ok ouais, très clair. Donc ça, tu expliques que vous êtes encore en cours de travail sur cet aspect-là. C'est quoi peut-être les plus gros challenges auxquels vous faites face aujourd'hui ? Et les premières pistes de réflexion là-dessus ?
Maud : Avec le content, les premières pistes de réflexion, c'est les feedbacks, et notamment la gestion des erreurs. En fait, je ne sais pas vous, mais vous, tout le monde, je ne sais pas toi, mais les erreurs coulent dans un produit quand ça ne se passe pas bien, mais quand ça va, c'est cool, et le message d'erreur est utile, permet de ne pas rester bloqué, ou est rigolo, tout ça, tous ces messages d'erreur en fait, ça te fait passer finalement un pas si mauvais moment, même si ça peut être très irritant et tout. Si ton erreur est bien réussie dans un produit, franchement c'est well done, c'est vraiment bien joué.
Terry : — Ouais, là-dessus, je partage totalement, clairement.
Maud : — Et en fait, du coup, les erreurs, souvent, elles sont un peu laissées de côté parce que les designers, les PM, les techs aussi, ils ont tendance à designer le happy path parce qu'on a tous envie que ça se passe bien.
Terry : Et tu te retrouves avec un «.
Maud : Something went wrong » ou « a problem has occurred » qui n'est parfois pas traduit. Ça, c'est le premier axe, c'est vraiment les feedbacks. Autour de ça, le content va aussi au-delà juste du contenu. Il peut aussi travailler ensemble pour dire que ce message-là doit être persistant, par exemple. Il ne peut pas s'effacer au bout de 10 secondes. Donc il y a vraiment aussi de l'UX, c'est pour ça qu'on est des UX writers et des content designers, ça va au-delà de juste le contenu. C'est aussi prescrire le fait qu'une alerte erreur, elle est peut-être tout le temps persistante et elle ne va pas disparaître au bout de 10 secondes parce que du coup, l'utilisateur peut potentiellement être bloqué.
Terry : Hyper claire et c'est vrai que ça, ça rappelle aussi l'intérêt, la complexité du design system et son intérêt vraiment de prendre du recul sur la globalité du produit, c'est-à-dire d'avoir un comportement homogène aussi à ce niveau-là, parce que si t'as une erreur à un moment qui pop et qui reste pendant cinq secondes versus à d'autres endroits, elle reste en permanence là, on pourrait se dire bon bah ça n'a pas d'importance en réalité, ça en a énormément sur le long terme, sur l'usage du produit. Et derrière aussi sur la montée en compétences des utilisateurs parce que ça permet un onboarding beaucoup plus fluide quand ils savent qu'un comportement est le même de partout. Une fois que tu l'as compris, tu as compris pour l'ensemble du produit. Donc il y a aussi cet aspect apprentissage. Du coup, ça me fait penser à une question, on n'avait pas spécialement parlé en off, mais sur ce sujet de l'apprentissage du produit. un peu des... un mécanisme d'onboarding ou en tout cas de... oui c'est ça, d'onboarding et derrière de formation, comment vous gérez la formation des utilisateurs ? Est-ce que c'est du... ? Enfin, ouais.
Maud : — C'est un de nos sujets, c'est marrant, c'est un de nos sujets en ce moment. Donc il y a forcément des onboarding, c'est un... Brevo c'est un produit relativement complexe avec vraiment beaucoup de petits outils les uns à côté des autres qui permettent du coup d'avoir... Tout ce qu'il faut pour faire une relation client, enfin pour gérer sa relation client au mieux, il y a des onboarding. Ce sont des sujets qui sont traités par tribe. On a quand même une tribe qui s'occupe vraiment du cycle de vie de l'utilisateur et donc il va faire attention à ça et notamment à unifier ses parcours d'onboarding. Et on a des patterns justement autour de ça qui sont en train d'être créés, de la même façon c'est toujours très long, sur le Creature First, comment on fait pour créer son premier deal dans le pipeline de vente, comment on fait pour créer sa première campagne, ou créer son premier meeting. On a ça, on a aussi tous les antistates qui doivent être potentiellement plus intéressants que juste un antistate. Et on a les tips, le pattern d'astuces, qui va finalement recommander une façon de faire les choses correctement, ou carrément donner vraiment un lien vers le help center qui permet du coup d'avoir plus d'infos sur des choses assez complexes, l'import de contacts, le fait d'avoir les segmentations, etc. Tout ce qui est un peu plus fin. Donc ça c'est inscrit et c'est dans le design system et ça fait partie des patterns que doivent appliquer aussi les designers.
Terry : — Oui, donc c'est un autre élément de contexte qui apparaît et qui est géré au niveau du design system. Donc si ça, ça évolue, c'est aussi au niveau du design system que ça sera mis à jour.
Maud : — Oui, exactement. Et le design system, il évolue aussi uniquement avec les product designers. C'est-à-dire que le design system ne va jamais créer un composant qui n'a pas été demandé et utilisé déjà par les product designers.
Terry : Et du coup ça me fait une parfaite transition sur la partie contribution du design system. Comment vous le gérez aujourd'hui ? Tu parlais d'un premier succès de mise en place quand on te demande est-ce que tu peux me créer ce composant ? Ça veut dire que du coup effectivement tu as réussi à gagner la confiance des équipes qui l'implémentent parce que souvent l'un des problèmes c'est que tu fais un premier design system qui est utilisé en one shot une fois Et après en fait les équipes se disent bon c'est bon je vais modifier de mon côté et en fait tu perds évidemment l'intérêt de centraliser ça et donc après tu te retrouves d'ici quelques années avec encore un truc éclaté où tu as des comportements qui sont pas homogènes. Donc tu t'expliquais que vous avez déjà cette chance d'avoir des gens qui vous demandent de créer des composants donc l'adoption plutôt cool. Mais comment vous gérez parce que parfois du coup si on a beaucoup qui te demandent en même temps, les équipes disent système.
Maud : Juste pour info, on est une équipe de design system, on est deux designers et on est cinq devs dédiés uniquement. Donc en fait, on ne peut pas répondre aux besoins des 50 devs et des 25 personnes qui sont dans le mix team. Ce qui se passe, c'est qu'on a mis en effet en place des systèmes de contribution, que ce soit côté dev ou côté design. Côté design, il y a des règles un peu plus strictes que les devs parce que les designers vont initier finalement les changements dans le design system d'une certaine façon. Ce n'est pas toujours le cas. Parfois, ça vient des devs aussi pour d'autres questions beaucoup plus techniques, beaucoup plus sur l'accessibilité ou ce genre de choses. Pour les designers, ce qui se passe, c'est qu'on a une règle, on n'intègre pas un nouveau composant s'il n'a pas été utilisé au moins trois fois dans l'app, et trois fois, c'est la moyenne basse, c'est le minimum syndical. Donc ça, tous les designers le savent. Très vite, la première réaction, c'est ouais, mais du coup, ça va tuer la créativité, etc. Non, ce n'est pas le but du jeu. Le but du jeu, c'est juste d'intégrer les choses scalables, reproduisibles et dont tout le monde potentiellement a besoin, de les intégrer dans le design system, de les maintenir, de les rendre accessibles, de les faire évoluer dans le temps. S'il y a des one-shots, c'est tout à fait possible. On demande juste aux designers d'utiliser les tokens, les petits composants simples du design system. Pour ça, ils ont un fichier expérimental, la Lab Component Library, où ils sont censés gérer, je dis censés, c'est pas toujours le cas, mais en tout cas, ils gèrent leurs propres composants. Ils doivent faire un peu du lobbying et donc présenter leurs composants aux autres designers pour éventuellement faire en sorte qu'ils utilisent leurs propres composants. Voilà. Un exemple de composant, ça a été la variante small du bouton. Dans un premier temps, on l'a intégré au design system évidemment, mais dans un premier temps, on leur a dit, nous on veut bien le faire, mais si c'est utilisé qu'une fois dans l'app pour ton besoin très spécifique, je préfère que tu le fasses toi avec tes devs. Et donc très vite, on a réussi quand même à avoir ces moments de partage où on discute le composant, est-ce que vraiment c'est un vrai composant design system ou pas, ou est-ce que finalement peut-être que tu peux tester en one shot déjà si ça marche. et donc de vérifier et d'itérer et ensuite on l'intégrera au design system. Ça c'est une première partie, après pour des contributions, ça c'est vraiment la création d'un composant.
Terry : Juste garde ce que tu as pour après, c'est juste pour rebondir sur ce que tu viens de dire par rapport à l'utilisation des tokens, donc même dans la création des composants en one shot, ce que tu dis, c'est qu'effectivement, les designers utilisent les tokens qui sont dans le design system et les tokens les plus granulaires, les plus petits, donc la couleur, le border radius, etc., donc qui permettent quand même de conserver une homogénéité évidemment au niveau purement de l'UI, et après, ils sont censés aussi connaître les guidelines de base sur les interactions, et du coup, permettre aussi de garder cette homogénéité au niveau aussi interaction. Donc, ce n'est pas parce que le composant n'est pas complètement intégré dans le design system pour être réutilisé à d'autres endroits, qu'il va faire péter l'expérience utilisateur.
Maud : C'est pas parce qu'un composant ou une UX n'est pas dans le design system que ça veut dire qu'il n'est pas design system compliant. Potentiellement, on a plein de parties du produit qui ne sont pas dans le design system et c'est OK. Juste, on fait en sorte qu'on ne réinvente pas la roue des tokens.
Terry : — Ouais, donc ça permet vraiment... C'est un très bon point dont tu parlais juste avant aussi, la scalabilité, c'est-à-dire que l'intérêt aussi du design system, donc il y a la première couche, qui est loin d'être simple, mais qui est l'homogénéité globale sur les comportements de ton application, donc qui permet d'aligner tout le monde sur, voilà, c'est comme ça que ça se passe au niveau interaction, etc. Et donc ça, ça doit être, que ce soit des composantes dans le design system ou pas, les designers doivent s'inspirer de ça pour designer des choses. Et ensuite, on intègre des composantes dans le design system en tant que telle, si jamais on sait qu'on va les réutiliser dix fois, enfin, le chiffre c'est.
Maud : Trois, mais après... Trois, c'est vraiment tout petit. Il y a des composants qui sont utilisés plus que trois fois, qui ne sont toujours pas intégrés dans le design system, parce que le design system, typiquement, parce qu'il ne sera jamais accessible, il ne sera pas dans le design system dans ce cas. Parce que ça fait partie de nos bases, de créer des composants accessibles. Ça peut être aussi des composants qui sont cools à première vue, et puis très vite, ils sont réutilisés, mais ils ne sont pas besoin d'utiliser. Ça, des misusages, il y en a partout dans les design systems, et donc c'est pour ça qu'il faut être prudent. En fait, le design system, souvent, on est prudent. C'est ce que j'ai... Les impacts, ils sont trop importants pour qu'on n'ait pas un peu de prudence, et donc souvent, le design system est un peu plus lent. On prend des décisions, ce n'est pas grave si ça nous prend deux mois pour dire bon allez finalement on le fait le composant. En fait ce n'est pas grave, le but c'est de ne pas être un goulot d'étranglement et donc de laisser quand même libre cours avec les bases du design system, les tokens, les petits composants de base qui ne changeront pas. De quand même laisser libre cours et la possibilité de créer du custom en fait.
Terry : Du coup, je t'ai coupé quand tu allais partir sur la deuxième partie des contributions.
Maud : Oui, la deuxième partie des contributions, ça va être les plus ou moins larges contributions à un composant qui existe. Donc, rajouter une fonctionnalité, rajouter un style, rajouter ce genre de choses. Dans ce cas, on va demander au designer de passer par le lab, de nous montrer vraiment ce qu'il veut, d'expliquer aussi le besoin. Donc on passe aussi par les user stories, ce genre de choses, pour bien comprendre quel est le problème en fait. Toujours, on est toujours en fait, on est le product designer des product designers au design system. Donc en fait on cherche à comprendre quel est vraiment le problème. Et à ce moment-là, les designers, souvent c'est plutôt bien fait, et nous on va réintégrer directement le design côté design system dans la libre, Figma, et côté dev, on peut leur demander aussi de contribuer. Très récemment, c'était rajouter une icône devant une collapsible section, donc c'est vraiment le principe de drop-down sur un titre. Et bien il n'y avait pas d'icône dans ce composant, parce qu'on essaye d'enlever un peu les icônes dans le produit en ce moment. Donc on ne l'avait pas mis de façon complètement délibérée, et finalement ça a été un besoin qu'on a permis de rajouter. C'est une contribution d'un développeur.
Terry : J'aimerais revenir sur un point que tu disais juste avant, sur la partie où on n'intègre pas de composants s'ils ne sont pas accessibles. Tu parles vraiment de l'accessibilité au sens de personnes qui peuvent avoir besoin de scanners d'écran ? C'est dans ce sens-là que tu parles ?
Maud : L'accessibilité, c'est un sujet qui me sent vraiment à cœur. L'accessibilité, c'est assez large. Ça touche tout type de personnes, en fait. Ça peut te toucher toi, quand t'es dans le métro ou quand t'es en plein soleil, voilà, et que tu es en train de regarder ton écran de téléphone et qu'en fait t'as pas assez de contraste sur une interface, ben tu dis rien. Donc t'as beau rajouter le maximum de.
Terry : Lumière possible, Comme du noir sur fond rouge, c'est pas mal ça.
Maud : Par exemple, voilà, ce genre de choses. En tout cas, voilà, il y a le premier niveau, ça va être le contraste, qui est quelque chose d'assez atteignable très vite. Après, on a aussi, pour des produits un peu plus tech, on peut penser à la navigation clavier. Les devs, je pense qu'ils fonctionnent que à la navigation clavier.
Terry : Et clavier mécanique.
Maud : Et clavier mécanique s'il vous plaît, avec des petites touches personnalisées. Non mais voilà. Donc en gros, voilà, ça peut toucher les devs aussi, l'accessibilité, donc avoir une navigation au clavier. Et après, il y a la couche aussi screen reader, qui est méga intéressante du coup avec le contenu. Comment gère les contenus cachés ? Je sais pas, un truc tout bête, c'est... un bouton view dans une interface, potentiellement dans une même interface, il y a view settings, view logs, view machin, et c'est sur la même interface. Comment quelqu'un qui ne voit pas l'interface peut interpréter un bouton qui n'a pas d'arrière-label ? C'est ok pour le bouton de dire view pour un... pour un utilisateur lambda. Pour quelqu'un qui ne voit pas l'interface, c'est directement un peu plus compliqué. Et donc, on va rajouter un aria-label qui va préciser qu'en fait, il est en train d'aller voir les settings, par exemple.
Terry : Donc pour les moins tech, l'arrière label c'est vraiment un bout qui est écrit dans le code, qui va décrire du coup quelle est la fonctionnalité de ce bouton là. Et si on reste ultra générique et qu'on n'en met pas, bah en fait le screen reader va lire le texte du bouton, mais si on met juste VIEW sur le bouton, ça va pas trop informer.
Maud : Ça va juste dire VIEW, et du coup c'est pas suffisant en fait pour faire la distinction entre trois boutons VIEW.
Terry : Donc ça, vous, vous le prenez en compte aussi, c'est-à-dire que s'il y a typiquement un bouton qui n'a pas d'arrière-label, vous dites, ben non, il faut en rajouter un pour qu'il soit intégré dans le design de système ?
Maud : Alors, c'est pas exactement comme ça. Nous, on va prévoir en amont toutes les places pour l'accessibilité. C'est-à-dire qu'on va prévoir la navigation au clavier sur le composant Select. Et donc, ça, c'est vraiment du web pattern, genre, c'est des conventions. Donc voilà, on va prévoir ça. Et puis, si on voit que... Par exemple, tous nos boutons, tous nos icons, buttons, voilà, en vrai, c'est pas très accessible. Sauf que s'il y a un tooltip à chaque fois qu'on hover dessus et qu'il nous dit de quoi il s'agit, déjà, ça c'est plus accessible. Et ensuite, l'aria label, donc, doit être dit. On va pas... s'il n'y a pas d'Arialabel globalement, un paramètre, le bouton, il va dire Cogwheel, ça ne veut rien dire. Ça ne veut rien dire, il va donner le nom de l'icône qui est dessus. Et en fait, là, on perd le contenu intéressant. Donc ça, nous, on le prévoit dans le design system et on note, il y a un champ, il y a une propriété dans le composant qui dit ça, c'est l'Arialabel, ça, c'est le contenu, ça, c'est le contenu du tooltip et ainsi de suite.
Terry : — Top, ça c'est hyper intéressant, c'est un point qui commence petit à petit à prendre de l'ampleur quand on parle d'utilisabilité en fait. Effectivement parce que les personnes, qu'elles soient déficientes visuelles, qu'elles aient des problèmes de compréhension aussi, il y a différents sujets comme ça. sur lesquels pour le coup un des leaders dans le secteur c'est tous les produits Apple et qui sont connus pour les personnes justement déficientes à différents niveaux parce qu'ils ont intégré ça très très tôt dans l'usage de leurs produits. Et aujourd'hui c'est bien de voir du coup des gens comme toi là qui disent bah oui on le prend vraiment en compte assez tôt. Et c'est un point hyper intéressant, c'est pour ça que je voulais revenir dessus quand je t'ai entendu parler de ça, je dis ah ça c'est un bon point. Du coup, je trouve qu'on a fait un tour assez global de qu'est-ce que c'est que faire un design system dans un contexte de rebranding, mais peut-être qu'il y a un sujet en particulier que tu aimerais accentuer ou un point qu'on n'a pas abordé, je ne sais pas.
Maud : Je crois qu'on a abordé à peu près tous les sujets et l'accessibilité, je suis très contente de l'avoir abordée. C'est une partie essentielle du travail du design system et c'est peut-être la partie finalement qui ennuient le plus nos designers et nos développeurs. Parce qu'en fait, il y a des choses qui sont complètement interdites, et donc on les frustre un peu.
Terry : Très, très clair. Mais c'est pour évidemment des bonnes raisons.
Maud : Pour le mieux, oui, pour le meilleur.
Terry : Du coup, pour aller vers mes deux questions de fin, donc la première, c'est est-ce que tu as des convictions fortes avec lesquelles tu te retrouves en général en désaccord avec tes pairs ?
Maud : Bah l'accessibilité, très clairement. L'accessibilité, le problème c'est que c'est du change management et donc il faut potentiellement le prévoir. Et donc là, il faut convaincre les PM, les product designers, les devs de prendre aussi un peu de temps pour ça. Ça se développe, l'accessibilité. C'est de plus en plus demandé dans les appels d'offres, sur les marchés publics en France. Si on est à l'étranger, c'est extrêmement regardé, aux États-Unis par exemple. Et donc, je pense que ça va de plus en plus se démocratiser. Je crois vraiment qu'il faut... En fait, il faut se dire que rendre quelque chose accessible, c'est forcément rendre le produit meilleur. Voilà. Ça, c'est un truc... J'y crois dur quand même faire, c'est-à-dire que... L'accessibilité c'est la base pour permettre à tout le monde de comprendre un produit qui est plus ou moins complexe et parfois très complexe et donc finalement ça ne peut qu'élever le produit.
Terry : — Hyper clair, et là-dessus, comme tu disais, je partage pour le coup ton avis, mais c'est vrai que ça peut être frustrant parfois, ça va ralentir certaines choses parfois aussi, donc c'est pour ça que dans certains contextes, on peut se dire « bon, on verra ça plus tard », mais il faut faire attention quand on se dit « on verra ça plus tard », pas attendre trop tard parce que... — C'est très long, ouais.
Maud : Vraiment, c'est du change management, il faut le prévoir, ça se fait comme une fonctionnalité en fait. — Yes. — Voilà.
Terry : Très, très clair. Et du coup, pour aller vers ma dernière question, c'est un peu les choses qui te nourrissent intellectuellement. L'idée derrière ça, c'est vraiment de comprendre comment toi aussi tu réfléchis et tu t'inspires.
Maud : Alors, pour les design systems, vraiment, j'ai des bibles, je lis des design systems. Mes préférés, ça va être Carbon, notamment pour l'accessibilité. Ils expliquent très bien comment ils rendent accessibles leurs composants, matériel, évidemment. Human Interface d'Apple, évidemment. Adobe Spectrum. Voilà, il y a vraiment beaucoup de design systems. Il y a Atlassian aussi, il y a GitHub, tout ça. Ce que je vais regarder aussi c'est d'autres produits, GitHub par exemple qui est des produits peut-être très techniques finalement où ils sont assez innovants. Des librairies React, finalement on est très en lien, le design system on est très très en lien avec la tech en fait en réalité. Et donc il y a pas mal de librairies React pour voir comment les composants sont créés, quelles sont les interactions. aussi comment il fait de l'accessibilité, enfin les trucs vraiment très techniques où finalement ça peut nous donner des idées. Evidemment, des produits plus cool, je veux dire, le visual design de façon générale, donc ça peut être Medium, Dribbble, tout ce qui passe, même juste des nouvelles applis où on sait que... Moi j'ai des potes qui me disent, il faut que tu regardes cette appli, elle est vraiment bien faite et tout, c'était trop bien. Et après j'ai une personne que je suis vraiment, que je trouve vraiment très très perspicace et pour le design system, c'est Ellie Youg. Je ne sais pas comment ça se dit. Je ne sais pas comment ça se dit, il y a plein de H. Je mettrai le lien, pas de souci. Et elle, je la trouve extrêmement pertinente sur sa façon de penser le design system. elle pense le design system comme un outil à grande échelle, pas uniquement pour le produit final, quoi. Potentiellement, ça peut passer dans les illustrations, par exemple, le design system et tout, et comment on s'adresse aux utilisateurs de façon globale, mais aussi comment on s'adresse aux designers et finalement à nos collaborateurs, quoi. Donc ça, j'ai trouvé ça méga intéressant.
Terry : Top, merci pour tous ces partages Maud, et puis si les personnes qui nous écoutent souhaitent te contacter, n'hésitez pas à contacter Maud si vous travaillez sur des design systems, même pour échanger des problématiques communes ou lui faire un retour sur l'échange, quel est le meilleur endroit pour le faire.
Maud : Alors, il y a les slacks dédiés au design system. Si jamais vous êtes féru de design system, il y a design system France, design system monde, 08 aussi, très bons slacks. Donc, je suis dispo clairement sur ces plateformes-là, et sinon, LinkedIn, évidemment.
Terry : Top. Eh bien, je mettrai le lien, au moins LinkedIn, dans les ressources, et après, pour ceux qui sont sur les slacks, ils pourront directement te MP. Merci encore pour ton partage, Maud.
Maud : Merci.
