Concevoir des systèmes dans les grandes organisations : quand la cohérence est une décision de gouvernance et non d’esthétique
Un système de conception bien construit n’est pas un ensemble de boutons et de polices. Il s’agit de décider comment une organisation assure la cohérence lorsque des centaines de personnes créent le même produit. Et cette décision est une décision d’orientation, pas de conception.
Un système de conception n'est pas une bibliothèque de composants. C'est une décision du gouvernement.
Il y a une conversation que nous avons souvent avec de nouveaux clients. Cela commence lorsqu'ils nous disent qu'ils ont déjà un système de conception, et cela se termine lorsque nous leur demandons qui décide de ce qui y entre.
Si la réponse est « il y a une équipe qui gère ça », on est bien. Si la réponse est « ça dépend », « ce n’est pas clair » ou « chaque équipe a quelque chose de différent », le problème n’est pas le système, mais la gouvernance qui l’entoure.
Ou plutôt son absence.
L'erreur de traiter un système de conception comme un produit de conception
La plupart des systèmes de conception échouent pour la même raison : ils sont conçus comme s’il s’agissait d’un produit de conception alors qu’en réalité ils sont une infrastructure organisationnelle.
Un produit de conception a une équipe de conception, une équipe produit, des utilisateurs et un objectif. C’est itéré, c’est amélioré, c’est lancé. La qualité se mesure en termes d'utilisabilité, d'adoption et d'impact sur l'entreprise.
Un système de conception a tout cela, plus quelque chose qu'un produit de conception normal n'a pas : plusieurs équipes qui en dépendent pour créer leurs propres produits. Des équipements avec des besoins différents, avec des délais différents, avec des critères esthétiques différents et avec différents niveaux de compréhension de ce qu'est le système et à quoi il sert.
La gestion de cette complexité n’est pas un problème de conception. C'est un problème de gouvernement.
Que signifie gouverner un système de conception
Gouverner un système de conception signifie avoir des réponses à ces questions :
Qui peut proposer des modifications au système ? Une équipe, ou seulement quelques-unes ? Avec quel procédé ?
Qui approuve les changements ? Un comité, une personne, l'équipe qui gère le système ? Avec quels critères ?
Comment les changements sont-ils communiqués à toutes les équipes qui dépendent du système ? Combien d'avance ? Avec quels documents ?
Que se passe-t-il lorsqu'une équipe a besoin de quelque chose que le système n'envisage pas ? Pouvez-vous faire une exception ? Dans quelles conditions ? Qui sait ?
Comment le système évolue-t-il lorsque la marque ou le produit change ? Avec quel processus de migration pour les produits déjà en production ?
Ces questions ne trouvent pas de réponse dans Figma. On y répond dans un document de gouvernance que l'équipe comprend, accepte et respecte – et dans une culture organisationnelle qui l'applique.
Le modèle de fédération
Dans les grandes organisations où nous avons construit ou maintenu des systèmes de conception – groupes bancaires, compagnies d’assurance, opérateurs d’infrastructures – le modèle qui fonctionne le mieux est le modèle de fédération.
Dans le modèle fédéré, il existe une équipe centrale qui gère le système : définit les normes, approuve les modifications, communique les mises à jour. Mais les équipes produit disposent d'une certaine autonomie pour proposer des extensions au système, construire des composants spécifiques que le système de base n'envisage pas encore et adapter certains aspects aux besoins de leur produit.
Ce qu’ils ne peuvent pas faire, c’est simplement contourner le système. S’ils ont besoin de quelque chose de différent, il existe un processus pour le demander, le justifier et, si cela a du sens, le transmettre au système central afin que tout le monde en profite.
Cet équilibre entre centralisation et autonomie est ce qui rend le système utile pour les équipes produit et gérable pour l'équipe principale. Trop de centralisation et le système devient un goulot d'étranglement. Trop d'autonomie et le système se fragmente en semaines.
Pourquoi c'est particulièrement important dans le secteur de la banque et de l'assurance
Dans les secteurs hautement réglementés, la cohérence de la conception n’est pas seulement une question esthétique. Cela a des implications sur la confiance des utilisateurs et la conformité réglementaire.
Un flux d'intégration incohérent dans une application bancaire non seulement confond l'utilisateur, mais peut également soulever des doutes quant à savoir s'il se trouve au bon endroit, si l'opération est sécurisée ou si l'entité est digne de confiance. Dans un contexte où la fraude numérique est une réalité quotidienne, ces doutes ont des conséquences.
Un système de conception bien géré garantit la cohérence de tous les produits banque, quelle que soit l'équipe qui les a construits. Et cela garantit que lorsque des changements doivent être apportés en raison d'exigences réglementaires (une nouvelle déclaration de confidentialité, un nouveau flux de consentement), ces changements sont appliqués de manière coordonnée partout où cela est nécessaire.
Ce que nous avons appris
Nous construisons et maintenons des systèmes de conception pour les grandes organisations depuis des années. La leçon la plus importante n’est pas technique, elle est organisationnelle.
Le système de conception qui génère le plus de valeur n’est ni le plus complet, ni le plus sophistiqué, ni le plus beau de Figma. C’est celui que l’organisation utilise réellement. Et l’organisation n’utilise que le système qu’elle comprend, en qui elle a confiance et qui évolue avec ses besoins sans devenir obsolète ni se briser à chaque fois que quelqu’un propose un changement.
Pour que cela se produise, une gouvernance est nécessaire. Et pour que la gouvernance fonctionne, quelqu'un au sein de l'organisation doit la prendre au sérieux dès le début, non pas en tant que processus bureaucratique, mais en tant qu'infrastructure permettant de concevoir à grande échelle.