Dailymotion en 2018 était une plateforme de grande envergure : 8 000 utilisateurs, cinquante à cent éditeurs premium dont CBS, ESPN et la BBC, plus de 100 000 vidéos traitées chaque mois, et des équipes réparties entre Paris, New York et Marseille. L'équipe design était réduite par rapport à cette échelle. La capacité d'ingénierie était substantielle. L'écart entre ce que le design spécifiait et ce qui était construit était un problème récurrent, et il était presque jamais intentionnel. Les développeurs prenaient des décisions par défaut quand les spécifications étaient ambiguës, et ces décisions s'accumulaient en dérive.

La documentation était l'objectif déclaré

Quand j'ai proposé de construire la première bibliothèque de composants de l'équipe avec Storybook, l'argument que j'ai présenté à la direction portait sur la cohérence et la documentation. Des composants partagés, des états définis, une source unique de vérité pour l'interface. Cet argument était facile à formuler, et il était fondé. Mais il s'avéra ne pas être la valeur principale que la bibliothèque livrait.

La valeur principale était quelque chose que je n'avais pas pleinement anticipé : elle donnait au design un point d'appui concret dans les négociations avec l'ingénierie. Quand un développeur proposait de simplifier un composant, de sauter un état hover, ou de fusionner deux variantes pour réduire le temps d'implémentation, la conversation se déroulait auparavant dans Slack ou en standup, avec les deux parties affirmant des préférences sans référence objective. Désormais, je pouvais ouvrir un onglet de navigateur et dire : voilà la page sur laquelle on s'est accordés. Cet état existe. Il a été spécifié, relu et validé. Si tu veux le modifier, on passe par le processus de changement, on ne prend pas de décision unilatérale pendant un sprint.

Passer de l'opinion à la décision

La distinction est plus importante qu'elle ne le paraît. Dans une conversation design-ingénierie sans artefact, tout désaccord devient un affrontement d'opinions. Le développeur a une opinion sur ce que l'état hover apporte à l'utilisabilité. Le designer a une opinion sur les raisons pour lesquelles il compte. Les deux opinions sont informées, les deux sont défendables, et aucune ne résout la question. La conversation tourne en rond ou se conclut par un compromis inconfortable.

Quand il existe une spécification documentée, la conversation change de registre. La question n'est plus « penses-tu que cet état est nécessaire » mais « avons-nous une raison de déroger à ce qui a été convenu ». C'est une question substantiellement différente. Elle exige un argument substantiel, pas seulement une préférence. Les développeurs qui s'opposaient sans argument réel revenaient rapidement sur leur position, non pas parce qu'ils avaient tort, mais parce que la barre pour modifier une décision documentée est plus haute que la barre pour remporter un débat informel.

C'est ce que j'entends quand je dis que Storybook fonctionnait comme un outil de négociation. Il n'empêchait pas les développeurs de proposer des modifications. Il augmentait le coût de l'approximation désinvolte et améliorait la qualité des conversations qui suivaient.

La première bibliothèque atomique a changé les défauts de l'équipe

La bibliothèque de composants que j'ai construite était aussi la première tentative de l'équipe de design atomique dans Sketch : tokens de base, atomes, molécules, organismes, structurés de manière à rendre explicites les relations entre les composants. Cela a créé un second effet, plus discret. Les designers ont cessé de concevoir des composants de zéro pour chaque fonctionnalité. Les ingénieurs ont cessé de prendre des décisions locales sur l'espacement et la couleur quand la spec était ambiguë. Les défauts se sont déplacés vers le haut. Le chemin le plus facile est devenu le chemin correct.

Les équipes sous-estiment souvent cela. Un système de design n'est pas seulement un outil de gain de temps. C'est un mécanisme qui change ce qui requiert un effort actif. Avant la bibliothèque, produire un composant cohérent nécessitait une attention délibérée à chaque étape. Après, produire un composant incohérent nécessitait de s'écarter délibérément d'un standard partagé. Cette inversion a un effet cumulatif dans le temps.

La mise à jour et la maintenance comme conditions de l'autorité

Une bibliothèque de composants ne fonctionne comme outil de négociation que si elle est à jour. Un Storybook périmé est pire qu'aucun Storybook, parce qu'il crée l'apparence d'une source de vérité tout en pointant vers des spécifications qui ne reflètent plus le produit réel. Je l'ai appris rapidement. Chaque fois qu'un composant évoluait, mettre à jour la bibliothèque devait faire partie de la définition de terminé pour ce travail, pas d'une tâche reportée à plus tard.

L'effet durable portait moins sur Storybook en particulier et davantage sur l'habitude de spécification qu'il avait instaurée. L'équipe avait développé une tolérance plus élevée pour la précision et une tolérance plus faible pour l'ambiguïté. Quand une nouvelle fonctionnalité était en cours de planification, la question « quels sont tous les états dont ce composant a besoin » était devenue routinière. Le coût de l'approximation avait été rendu visible, et les gens avaient expérimenté ce que c'était d'avoir une référence claire lors d'une conversation difficile. Cette expérience ne disparaît pas quand on ferme l'onglet du navigateur.