La phase opérationnelle pour un Design System [Part.4]
Nouvel article de cette série Design System dans lequel je vais aborder la phase de run de notre système.
Pour récaputiler les articles précédent nous avons donc :
- Fait un rappel de ce que l’on nomme Design System et ses fondammentaux (https://medium.com/%40guillaumect/les-fondements-dun-design-system-construire-des-bases-solides-pour-un-produit-num%C3%A9rique-coh%C3%A9rent-62add87e45d3)
- Réflechi à la statégie pour mettre en place efficacement un Design System (https://medium.com/%40guillaumect/strat%C3%A9gie-et-avantages-pourquoi-adopter-un-design-system-part-2-58a9977cc7cf)
- Construit notre Design System en intégrant toutes les parties nécessaires pour que celui-ci soit utile et utilisable par toutes les parties-prenantes dans l’entreprise (https://medium.com/@guillaumect/la-phase-de-conception-dans-un-design-system-part-3-5b51607adeba)
Il nous reste à aller explorer la vie de ce Design System maintenant mis en place ! Que va-t-il lui arriver ? Comment faire en sorte que les éléments Design et Dev soient maintenu à jour ? Comment faire pour que notre documentation soit la bonne ? Comment faire pour que notre System soit toujours pertinent/optimal ? Existe-t-il un rôle dédié à la supervision du bon fonctionnement de ce workflow ?
Je vais vous partager mon retour d’experience et mes connaissances sur le sujet vulgarisant les choses pour qu’elles soient compréhensibles pour toutes et tous :).
Aller, suivez le guide !
“Un Design System réussi doit devenir une partie de l’ADN d’une organisation, qui aide votre équipe à produire des expériences utilisateur plus cohérentes, et qui établit également des ponts entre la conception et le développement.”
Ce qui est souvent le cas lorsqu’un Design System est mis en place, c’est une adhésion difficile des équipes et des personnes n’étant pas directement impliquées dans la construction et la mise en place de celui-ci.
Résistance au changement, peur de casser les interfaces déjà faites, sentiment de recommencer à zero, je ne sais pas comment faire, flèmme.. autant de retours entendu et vécu qui sont souvent le résultat de mauvaises explications données en amont.
Le Design System est un socle fondemental de l’entreprise sur lequel tout le monde dans l’entreprise pourra et devra se reposer car il assurera une cohérence globale pour le produit.
“Communiquer encore et toujours”
Le système est une chose presque vivante qui évolue avec son temps, avec les besoins de l’entreprise, les réorganisations, les évolutions techniques, les évolutions de process etc.
On peut regrouper les choses sous trois axes :
- l’organisation
- les équipes
- les outils.
L’organisation
Dans ce que j’appelle l’organisation il faut identifier les évolutions et les améliorations nécessaire pour que l’utilisation du system soit toujours pertinent et apporte de la valeur ajoutée.
Cela peut être dans l’amélioration du processus de fonctionnement par exemple passer d’un fonctionnement Sketchapp + Zeplin à uniquement Figma avec la vue devmode intégrée parce que finalement les devs de l’entreprise s’y retrouvent bien et vont plus vite qu’en ajoutant un outil supplémentaire à leur workflow. La qualité du code est similaire ou demande peu d’ajustement dans le cadre du projet.
Il peut autrement être question de challenger les rituels et points de rencontrer équipes car ils sont insuffisants ou trop nombreux, on ne parle pas des bons sujets ou alors ce ne sont pas les bonnes personnes invitées. Dans ce cas il faut se référer au plan d’organisation initial et restreindre à la team core du projet + ajouter si nécessaire des participants susceptibles d’améliorer le système lors de points dédiés.
Pour ce qui est des points de rencontre équipes, préciser toujours de qui il sera question et identifiez lorsque nécessaire les personnes clés ce qui facilitera la redescente ou la remontée d’informations.
La méthode de découpage des composants est peut-être à revoir car la façon de faire actuelle est trop complexe, ne parle pas aux nouvelles recrues, ne correspond pas au besoin du produit car trop lourde ou au contraire pas à assez robuste. Il sera peut être plus efficace avec l’utilisation de tokens design ? Gardez toujours un environnement de tests où vous pourrez essayer plusieurs méthodes et ajustements pour améliorer le système.
Les teams
“Est-ce qu’on maitrise la dernière mise à jour Figma ?”, “Est-ce qu’on ne mettrait pas à jour nos composants avec la nouvelle façon de faire que propose Figma ?” Sont des questions qui reviennent à chaque fois qu’une nouvelle feature sort.
Est-ce que toutes les personnes parties-prenantes dans le projet sont à même de maitriser leur périmètre dans le cas où par exemple de nouvelles recrues arrivent et d’autres s’en vont ? Comment bien les onboarder sur le DS ?
Le sujet des compétences est selon moi stratégie pour maintenir à flot un design system sur le plan technique. pour vous aidez à y voir plus clair je vous encourage à aller voir le modèle en T des compétences. Vous trouverez 2 articles à la fin de cet article en lien :).
Vous pouvez également réflechir à ce que l’on appelle la “minimal design team” ou encore aux compétences clés, compétences à éviter. Ainsi, vous pourez prendre mieux conscience de vos forces et aussi des forces complémentaires des équipes design et produit.
Il est important de mettre en place et de partager les instances de rituels/routines (les daily, les weekly, les monthly) tout en précisant à chaque fois ce qui est attendu dans ces moment là et pourquoi vous vous retrouvez, avec qui.
Nous ne sommes pas dans l’attente des mêmes informations lorsque l’on présente les évolutions Design System lors d’une monthly avec les autres équipes de l’entreprise ou dans une daily avec la core team ou il sera plutôt sujet du composant button qui a un comportement étrange et doit être fixed.
Il est nécessaire d’anticiper les planning de livraisons, la remonté de bug et fix nécessaires, les requêtes d’amélioration design et dev, les mise à jours de documentations, les moments de partages de façon à pouvoir projeter des réalisations faisables et d’ajuster si nécessaire.
Pensez à définir les règles de partages et de communication aussi bien en interne (au niveau de l’équipe mais aussi de toute l’entreprise) qu’en externe pour communiquer sur les évolutions majeures notamment si vous avez un système contributif ou réutilisable par des personnes hors de votre entreprise… ou ne serait-ce que pour communiquer au plus grand nombre de vos évolutions car vous et votre équipe êtes fier du travail effectué.
Faites en sorte de livrer vite et souvent pour avoir des retours, fixer et livrer encore et encore. C’est un bon mentra qu’il faudra s’efforcer de continuer à s’appliquer sinon on tombe vite dans des livraions loooooongues et parfois qui n’aboutissent pas (rip petit ticket fix de composant).
Les outils
Comme je le disais précédemment les outils évoluent, des fonctionalités sont apportés par les éditeurs ce qui peut amener à changer nos façons de travailler. Il est donc important de se tenir au courant et parfois de challenger l’utilisation d’outils au profit d’autres, certains plus efficaces dans les tâches que vous souhaitez réaliser.
“Devons-nous mettre à jour nos composants design system en prenant en compte les évolutions Figma ?” On peut se poser la question de la valeur ajouter de passer d’une façon de faire à une autre. Il faut questionner la courbe d’apprentissage de cette nouvelle façon de faire et si après coup il y a un vrai gain à faire cette MAJ ou plutôt rester sur “l’ancienne” façon de faire.
L’apport par exemple des variables dans Figma est une avancée importante pour ceux passant de composants sans variables interchangeables à ça. Pour ceux utilisant déjà Figma Tokens, cette maj ne change pas grand chose car Figma tokens est encore plus puissant et conserve une longueur d’avance.
L’intégration du dev mode est intéressant car maintenant natif dans Figma mais il y a encore des choses perfectibles (code trop lourd, peu véloce, pas encore suffisamment pertinant car les développeurs utilisent des frameworks CSS type tailwind ce que ne propose pas Figma..).
Tout ceci demande donc de revoir le workflow général car des outils ne sont plus utiles ou peuvent mieux faire. A l’inverse, il est parfois plus intéressant de rester sur des outils déjà en place car plus robustes même s’il n’y a pas la feature un peu sexy dedans.
Ne pas oublier d’integer les mécanismes de validations et feedbacks dans vos utilisation d’outils qui seront utile pour vous permettre un suivi général du Design System. Sans quoi vous irez plus ou moins vite à un état de blocage ou de montagne qu’il ne sera plus possible de gravire car tout sera devenu trop complexe, illisible et flou dans les échanges.
Un Design System c’est un langage commun entre la tech et le design. Les outils ne sont que les moyens permettant de passer de l’un à l’autre et de communiquer ensuite sur la vie de ce système. :)
Un dernier point Figma (et après j’arrête promis) permet d’avoir un monitoring des composants utilisés, par qui et dans quel projet ce qui vous permet également d’avoir un oeil sur l’utilisation ou non de composants et plus globalement du système à travers votre produit.
Enfin, et non des moindres, mettez à jour votre documentation !
Dès l’instant où un changement sera apporté à votre composant que ce soit en dev ou en design, il FAUT que vous mettiez à jour votre documentation si ce changement impact le comportement du composant, son aspect visuel ou son intéraction.
Un composant ne pourra être considéré comme valide que lorsque la doc, le design et le dev seront identiques.
Le Product Ops
Son rôle dans tout ça est d’être le chef d’orchestre du Produit de façon général pour le rendre le plus efficace possible. Il est en charge de rendre fluide les relations entre les outils, les équipes (sales, design, dev, marketing..) et le produit de l’entreprise.
C’est avec lui que vous allez traiter pour tout ce qui concernera les probématiques de licences outils, de workflow produit, de relations entre les teams, d’échanger sur la culture produit dans l’entreprise, de mettre à dispo les bonnes ressources etc... Il partagera la roadmap à tous, veille sur les OKR, comunique les infos produits ou oriente vers les bonnes personnes.
Il a un rôle très important dans la mise en place du Design System car c’est avec lui que vous devrez vous aligner de façon à ce que la communication se fasse efficacement et que le projet DS infuse dans tous le produit ou bon moment et avec les bonnes personnes.
Le rôle de Product Ops est généralement occupé par 1 personne identifiée comme telle, parfois le rôle est occupé par plusieurs personnes (cf Doctolib) et dans d’autres cas lorsque les entreprises sont moins matures sur le sujet il n’y a pas de poste Product Ops dédié, ce sont des fractions du rôle qui sont réparti souvent entre les PM.
Voilà j’espère que cet article vous aura plu et vous aura permis d’y voir plus clair, de mieux comprendre certaines choses quant à la vie de design system une fois live.
Il n’y a ici qu’une vue macro de ce que recouvre réellement un design system live mais l’idée n’est pas de rentrer dans les détails, simplement de vous permettre d’avoir une meilleure compréhension du sujet et d’avoir des billes pour échanger avec vos collègues ou supérieurs à ce propos. :)
Merci de m’avoir lu et on se dit à bientôt pour d’autres articles connexes ! 👋 D’ici là portez vous bien et rendez-vous sur linkedIn 🤓
