Nous avons désormais vu mourir quatre design systems. Des entreprises différentes, des outils différents, la même autopsie : une belle bibliothèque, un site de documentation que personne n’ouvrait, et une équipe produit qui construisait tranquillement ses composants à côté.
L’explication habituelle est « nous n’avons pas eu le temps de le documenter ». Nous n’y croyons plus. Chacun de ces systèmes avait une documentation. Ce qui leur manquait, c’était une raison de continuer à s’en servir un mardi difficile.
Un système construit à l’écart est une proposition, pas un système
Ceux qui ont échoué ont tous été construits de la même façon : un designer disparaissait deux ou trois mois, puis présentait une bibliothèque terminée. Elle était complète, cohérente, et complètement déconnectée des écrans que l’équipe livrait réellement ce trimestre-là.
La première fois qu’une vraie fonctionnalité a eu besoin de quelque chose que la bibliothèque n’avait pas, quelqu’un a fait une exception. La deuxième exception a pris dix minutes à justifier. À la cinquième, la bibliothèque était un musée.
Un composant pour lequel personne n’a eu à se battre est un composant que personne ne défend.
Ce que nous faisons à la place
- Construire à partir d’écrans réels. Aucun composant n’entre dans la bibliothèque avant d’être apparu à deux endroits différents du produit réel. La deuxième apparition prouve que c’est un motif et non un cas isolé.
- Nommer un responsable par section. Pas un comité. Une personne que l’on sollicite quand un bouton a besoin d’un nouvel état.
- Budgéter la maintenance à voix haute. Nous chiffrons le travail de design system comme une ligne récurrente, pas comme un livrable ponctuel. Un système sans budget de maintenance a une date de décès programmée, et tout le monde devrait le savoir.
- Faire du raccourci le bon chemin. Si aller chercher dans la bibliothèque est plus lent que copier-coller une div, la bibliothèque perd. À chaque fois.
La documentation, ce sont les derniers 10 %
Nous l’écrivons toujours. Mais après que le système a survécu au contact de trois ou quatre fonctionnalités, et nous la plaçons là où les développeurs vivent déjà — dans le dépôt, pas sur un site séparé qui demande un second identifiant.
Le seul des quatre systèmes encore vivant deux ans plus tard a la pire documentation du lot. Il a aussi deux responsables nommés, une heure bloquée chaque mois pour le nettoyage, et une règle : les nouveaux composants arrivent avec la fonctionnalité qui les a rendus nécessaires. Cela a compté davantage que n’importe quelle page de recommandations.