La gouvernance d’un Design System, entre modèle centralisé et fédératif

On ne dira jamais assez tout l’intérêt pour une structure d’avoir un design system. Il permet d’avoir des composants parfaitement ordonnés, des guidelines bien pensées, une documentation complète… et au bout du compte un vrai gain de temps pour l’équipe d’utilisateurs.

Overlord versus team

Il y a des années un design system pouvait encore être produit par un seul homme, régnant en maître. Si vous ne trouviez pas votre bonheur dans la bibliothèque de composants, il fallait faire avec. C’était lui le seul décideur.

Cette organisation n’est plus d'actualité.

Les grandes structures travaillent maintenant avec des centaines de designers qui planchent sur les sites web, les application natives, les outils métiers, l’expérience client ou l’expérience employé, et bien d’autres aspects.

Les product managers mettent la main à la pâte. Ils travaillent en équipe répartis dans toute l’entreprise et il n’est plus question de leur imposer quoi faire. 

Une chose est sûre, la gouvernance et la répartition des équipes autour d’un Design System va être structurante pour son évolution.

Il existe plusieurs modèles (détaillés par Nathan Curtis) mais deux d’entre eux semblent être les plus courants : modèle centralisé et modèle fédératif.

Modèle centralisé ou modèle fédératif ?

Il ne s’agit pas de décréter qu’un modèle est meilleur que l’autre. Il va - de fait - se choisir en fonction de l’organisation de la structure et du temps qui peut être alloué par chacun.

Dans un modèle centralisé, une équipe dédiée gère le système et le fait évoluer. Cette équipe doit être en relation étroite avec les autres équipes afin d’être sûre de couvrir tous les besoins et d’être proches de leurs problématiques quotidiennes. 

‍

Les autres équipes pourront faire des propositions de nouveaux composants ou de nouveaux patterns, mais le choix final de leur intégration ou non au système reviendra toujours à l’équipe centrale. 

Que l’équipe soit entièrement interne ou englobe une équipe de consultant (des designers d’agence à l’origine du projet par exemple), il est primordial que la chaîne de décision soit transparente et que l’implication des équipes soit complète. Un outil qui ne serait pas porté en interne mais imposé n’a que peu de chance de devenir pérenne. 

Les avantages de ce modèle sont double : 

• une allocation de ressource en entreprise (homme et temps) plus légère;
• une cohérence plus facilement maîtrisée des éléments du Design System. 

‍

Dans un modèle fédératif, des membres de plusieurs équipes sont en charge du système et y contribuent. L’adoption est souvent plus facile mais il faut des garants qui ont la vision transverse du système afin de garder une cohérence d’ensemble et qui restent disponibles. 

Il est également possible de tester une combinaison de modèles. Salesforce a, par exemple, dédié une équipe centrale au système “Lighting” qui s’appuie sur des contributeurs répartis dans l’ensemble de l’organisation.

Google design a opté lui pour la solution fédérative. Un petit groupe - aujourd’hui en augmentation - de designers forme ce qui est devenue Material Design utilisant une approche de comité par expérience.

Ces comités sont constitués de designers et de de décisionnaires désignés pour collaborer sur le système pendant un temps donné.

‍

‍

Ils prennent des décisions collectivement, construisent et communiquent via un support de leur choix (et ce choix est large).

Attention tout le monde ne participe pas ni n’a la possibilité de s’exprimer. Le groupe fait part de ses décisions aux autres équipes de production qui améliore leur résultat ou les ignore à leur risque et péril.

Les intérêts de constituer une telle équipe sont multiples : 

• accroître la pertinence de nombreuses plateformes et lignes de production
• limiter les biais en représentant de nombreux points de vue différents
• faciliter la circulation du système entre les équipes en multipliant le nombre “d’évangélistes”.

‍

En revanche cette option demande beaucoup de travail et de rigueur.

Par ailleurs les designers et développeurs qui participent à ce modèle doivent être capable de transcender de manière convaincante les enjeux de service pour le bien du parcours utilisateur le plus cohérent.

Enfin un modèle fédératif comme celui-ci entraîne également un vrai challenge au niveau des prises de décisions. Infailliblement des discussions vont naître sur un point de design lorsque les décisions seront communiquées. L’équipe doit alors équilibrer le besoin de prise de décision et d’avancement du projet avec des pauses où le degré d’implication sera plus large afin de répondre au besoin de chacun de donner son avis.

‍

Comment former une l’équipe qui va conserver la cohérence avec le design system conçu ? 

De nombreuses dimensions sont à prendre en compte lors de la constitution d’une telle équipe. Cela inclut : Qui est disponible ? Pour combien de temps ? Quand le design system doit il être achevé ? Qui a les compétences pour identifier et construire les éléments indispensables ?

Mais quelque soit le modèle d’organisation choisi, les rôles à embarquer dès le départ sont :

• les Designers (Product Designers et profils spécialisés),
• les Développeurs,
• un ou plusieurs Product Managers,
• les autres utilisateurs des assets (ex. : marketing, communication etc.),
• un sponsor soutenant l’initiative (primordial pour dénicher et motiver les talents dormants de la société).

Il peut être pertinent de nommer un responsable du Design System, chef d’orchestre de sa création et de son maintien, qui saura évangéliser sur son intérêt au sein de l’organisation. 

‍

Le process de gouvernance

Au-delà de l’allocation de ressources dédiées au Design System, la mise en place d’une gouvernance est indispensable afin de s’assurer que le système peut s’adapter aux changements. 

Ainsi, il faut commencer par répondre à certaines questions relatives à la façon de gérer les changements : qui valide les modifications apportées au système ? Que se passe-t-il lorsque l’on détecte des bugs ou régressions ? Comment traite-t-on les demandes de nouveaux composants ? 

En effet, si les utilisateurs ne trouvent pas ce qu’ils recherchent dans le Design System, il risque d’être rapidement obsolete et donc abandonné.

C’est tout l’enjeu de la mise en place par les équipes d’un process de gouvernance extrêmement clair et complet. Il doit permettre aux utilisateurs de savoir exactement quoi faire dans les cas où - entre autre - ils ne trouvent pas le composant adapté à leur besoin, ou s’ils ont des questions sur le design system.

Le problème se pose d’autant plus pour les grandes organisations, internationales ou pas, qui ont une multiplicité de localisation, de filiales, de produits, d’équipes.

Brad Frost, a par exemple créé une carte décrivant le process de gouvernance pour ses clients. Elle se présente finalement comme un logiforme amélioré ou chaque cas est étudié et une solution apportée.

Le job de l’équipe de production est de concevoir de nouveaux produits. Jusque là rien de nouveau. Dans l’idéal, ils trouveront dans le design system le composant dont ils ont besoin et qui répond à toutes leurs exigences. C’est le fameux gain de temps évoqué plus haut.