UNOWHY opérait cinq marques produit distinctes depuis une seule organisation d'ingénierie : SQOOL (la suite tablette éducative principale), SQOOL Extend (machines virtuelles), SQOOL Protect (filtrage de contenu et contrôle parental), Hi SQOOL (la plateforme de communication étudiante), et la marque corporate utilisée dans la communication institutionnelle. Huit applications ou plus, couvrant Android, Windows et le web. Chaque marque avait son propre product manager et sa propre identité visuelle. Aucune ne partageait de composants.
L'argumentaire pour un design system unifié était évident du point de vue de l'efficacité. L'argumentaire contre, du point de vue d'un product manager, l'était aussi : un composant partagé signifie que votre produit ressemble aux autres, avance à la vitesse des autres, et a sa roadmap contrainte par les autres. Amener cinq PM à abandonner cette autonomie nécessitait une conversation différente de celle que les designers tiennent habituellement.
L'architecture des tokens comme architecture politique
L'architecture Figma que j'ai conçue comporte trois couches. La couche brute contient des valeurs : des couleurs hexadécimales précises, des dimensions en pixels, des tailles de police sans signification sémantique attachée. La couche sémantique assigne une signification à ces valeurs : couleur/interactif/primaire, espacement/composant/défaut, typographie/titre/grand. La couche marque mappe l'identité visuelle spécifique de chaque marque sur la couche sémantique, en surchargeant les valeurs sans toucher à la logique des composants.
Cette structure en trois couches a résolu le problème politique plus que le problème technique. Un product manager qui comprenait que sa couche de tokens de marque était entièrement sous son contrôle, et que la modifier ne nécessitait aucune coordination avec les autres marques, était beaucoup plus disposé à accepter des composants partagés au niveau sémantique. Les composants partagés sont devenus une infrastructure plutôt qu'une contrainte : ils exprimaient l'identité de marque via la couche de tokens, pas via leur propre structure.
La conséquence pratique était qu'un composant bouton existait une seule fois, dans la fondation partagée. Le bouton de SQOOL était bleu avec un rayon de coin spécifique, exprimé via des tokens. Le bouton de SQOOL Protect était d'une teinte différente avec un poids typographique différent, également via des tokens. Le composant lui-même ne changeait jamais. L'expression de marque était entièrement localisée dans la couche de tokens.
Plus de temps en réunions d'alignement que dans Figma
Le récit honnête de la construction de ce système implique de reconnaître que le travail le plus difficile s'est passé dans des salles de réunion, pas dans Figma. Chaque PM avait un modèle mental des composants dans son produit qui étaient uniques et de ceux qui étaient génériques. Ces modèles mentaux étaient souvent faux, mais ils étaient tenus avec conviction car ils étaient ancrés dans la stratégie produit du PM.
Les sessions d'alignement les plus productives étaient celles où j'apportais des inventaires de composants existants : un audit visuel montrant chaque variante de bouton, chaque pattern de carte, chaque élément de formulaire dans les cinq produits. Quand les PM pouvaient voir côte à côte que leur composant « unique » était identique à 80 % à la version d'une autre marque, la conversation passait du principe aux spécificités. « En quoi exactement ces éléments doivent-ils différer ? » est une question plus productive que « faut-il partager des composants ? »
La réponse était généralement : la différence se situe dans les tokens, pas dans le composant. C'est exactement ce que l'architecture était conçue pour prendre en charge.
La maintenance comme condition de la confiance
Un design system qui n'est pas activement maintenu devient un passif plus vite qu'il est devenu un actif. Les équipes l'adoptent parce qu'elles font confiance au fait qu'il reflète les standards actuels et que quelqu'un est responsable de le tenir à jour. Dès que cette confiance s'érode, les équipes commencent à diverger : construire des variantes locales, contourner le système pour le travail « urgent », jusqu'à ce que le système soit techniquement présent mais pratiquement inutilisé.
Chez UNOWHY, j'ai traité le design system comme un produit vivant avec sa propre roadmap et ses propres notes de version. Quand un composant partagé était mis à jour, les cinq équipes produit recevaient une note de changement structurée : ce qui avait changé, pourquoi, ce qu'elles devaient mettre à jour dans leurs produits, et le calendrier attendu. Cette discipline de communication était plus importante que l'architecture des tokens pour maintenir l'adoption.
La réduction de 60 % du temps de conception était la métrique qui comptait pour la direction. Pour l'équipe design, le résultat le plus significatif était la cohérence : les décisions prises dans le contexte d'un produit informaient les autres, et l'écosystème a commencé à ressembler à une suite cohérente plutôt qu'à cinq applications séparées qui partageaient par hasard une palette de couleurs.