Encore : à quoi ressemble un design system déployé sur 45 plateformes

En 2019, la direction de Spotify a voulu rendre l'audio disponible et cohérent sur n'importe quel appareil. Les chiffres publiés par l'équipe design sont frappants : 45 plateformes uniques et plus de 2 000 types d'appareils répartis sur 200 marques. Un utilisateur lance une playlist sur la télévision du salon, la continue dans sa voiture et la reprend sur son ordinateur portable le lendemain matin.

Il ne s'agit pas simplement d'une version agrandie du problème habituel des design systems. C'est un problème différent. Un téléviseur se regarde à trois mètres, une montre doit tout condenser, un ordinateur de bureau dispose d'un espace conséquent et une voiture impose des contraintes légales sur l'interaction. Aucune bibliothèque de composants unique ne peut répondre à tout cela, et aucune documentation ne peut forcer un tel résultat.

Encore a été lancé avec deux segments. Encore Consumer Mobile était décrit comme incroyablement flexible, un vaste catalogue de composants en croissance constante pour des expériences centrées sur le mobile. Encore Web desservait une gamme plus large de produits web. Sous ces deux segments se trouvaient les design tokens couvrant les décisions fondamentales comme les palettes de couleurs et les styles typographiques.

Le modèle publié est concentrique. La foundation est au centre. Le Web et le Mobile se situent au-dessus en tant que sous-systèmes pairs avec une parité de plateforme. Plus loin se trouvent les sous-systèmes plus spécialisés (Content Web Platform, Advertising Web, Consumer Mobile), chacun divergeant progressivement du cœur.

L'intérêt de cette structure est que la divergence est bornée et localisée. Un composant dont seule la publicité a besoin réside dans l'anneau publicité, où il ne peut pas s'infiltrer dans l'application grand public. Une décision de couleur réside dans la foundation, où elle ne peut être modifiée localement. L'alternative — une bibliothèque plate unique pour tous — force chaque besoin spécialisé soit à être absorbé par le cœur, l'encombrant, soit à être construit en dehors du système, ce qui est le début de la fin pour tout design system.

Voici la partie rare dans les écrits publiés sur les design systems, car il s'agit d'un aveu. En 2022, l'équipe a jugé que le pendule avait trop basculé vers la flexibilité et qu'un recalibrage était nécessaire.

Ce qui s'est passé est reconnaissable. Consumer Mobile était délibérément flexible, si bien que les équipes produit lui demandaient des composants de plus en plus raffinés, et elle acceptait systématiquement. Une flexibilité qui commence comme une fonctionnalité devient une obligation : le besoin spécifique de chaque équipe devient un nouveau composant géré par le système, et le catalogue s'étend plus vite que quiconque ne peut le maintenir cohérent.

La correction apportée par Spotify est l'étape intéressante. Ils n'ont pas durci Consumer Mobile ni commencé à rejeter les demandes. Ils ont réuni une équipe pour concevoir des composants réutilisables pour Encore Mobile : en insérant une nouvelle couche entre Consumer Mobile et la fondation. La description officielle de son rôle est précise : elle agit comme une première ligne de défense, réduisant la charge pesant sur Consumer Mobile pour fournir chaque composant, tout en assurant une meilleure parité entre les plateformes sur le reste du système.

Cela recadre un problème de gouvernance comme un problème structurel. Lorsqu'un sous-système reçoit des demandes qui ne lui sont pas réellement spécifiques, le problème ne vient pas des demandes. Il vient de l'absence d'une couche partagée. Dire non aurait poussé ces équipes à développer en dehors du système. L'ajout de la couche a permis de capturer ce travail.

Le compte rendu de l'équipe sur le processus de travail est suffisamment concret pour être copié, et le changement crucial qu'ils mentionnent est que les composants multiplateformes sont désormais conçus comme tels dès le départ, plutôt que comme une réflexion après coup.

1. 1

   Réunir toutes les plateformes autour de la table

   Les représentants d'iOS, d'Android et du Web ensemble, avant toute conception. Leur argument sur la nécessité de cette approche est pertinent : il est rare de trouver un expert à la fois pour le web et le mobile, l'expertise doit donc être assemblée plutôt que supposée.

2. 2

   Chaque plateforme audite et schématise ce qui est unique à son interface

   Le desktop dispose de plus d'espace. La télévision est différente en raison de la distance de visionnage. Une montre nécessite une condensation de toutes les informations. Ces éléments sont énoncés comme des faits concernant l'interface avant que quiconque ne discute du composant.

3. 3

   S'aligner sur les termes, les états et l'interaction des propriétés

   Le groupe de travail définit la terminologie, les états existants et la manière dont les propriétés se combinent. C'est l'étape qui est souvent sautée, et c'est précisément ce qui fait que deux plateformes finissent avec un composant qui partage un nom, et rien d'autre.

4. 4

   Concevoir le composant en tenant compte de tout cela simultanément

   Pas une version par plateforme plus des adaptations. Un seul composant dont les variantes sont connues avant même d'être dessinées.

La troisième étape est celle qu'il faut voler, quel que soit le nombre de plateformes que vous avez. La plupart des dérives de composants commencent par une dérive de vocabulaire : le « secondary » d'une équipe est le « ghost » d'une autre, l'état « disabled » de l'une est le « read-only » de l'autre, et le temps que quelqu'un s'en aperçoive, les deux sont déjà livrés.

Recherchez le design system de Spotify et l'une des premières choses que vous trouverez est les Spotify's public Design & Branding Guidelines sur le site développeur. Il est important de préciser qu'il ne s'agit pas d'Encore, ni d'un design system au sens habituel. C'est un document de conformité.

Sa structure ne trompe pas : attribution, utilisation du contenu Spotify, navigation dans le contenu, liens vers Spotify, vues de lecture, affichage d'entités, utilisation du logo, utilisation des couleurs, restrictions sur le logo et la dénomination, polices. La raison invoquée pour les règles d'attribution est que le contenu disponible via Spotify appartient à de nombreux détenteurs de droits différents ; ainsi, toute utilisation des métadonnées de Spotify (noms d'artistes, d'albums et de pistes, illustrations, lecture audio) doit être accompagnée de la marque Spotify. La page précise que l'utilisation des ressources implique l'acceptation des conditions d'utilisation pour les développeurs.

La distinction est cruciale si vous développez quoi que ce soit qui intègre le contenu ou la marque d'un tiers. Ces règles sont contractuelles, et l'argument « c'était plus joli sans le logo » n'est pas une défense. Cela importe aussi en tant que catégorie : si votre produit est consommé par les produits d'autres personnes, vous pourriez avoir besoin de ce document en plus d'un design system, et ce ne sont pas les mêmes métiers de rédaction.

Le modèle concentrique se transpose directement aux directives de design écrites pour les agents de code IA, et il résout un problème qui apparaît dès qu'un projet possède plus d'un type d'interface.

L'échec classique consiste à utiliser un seul fichier DESIGN.md pour couvrir à la fois un site marketing, le shell d'une application et un tableau de données dense. Les règles finissent par être nuancées (« espacement généreux, bien que les tableaux puissent être plus denses »), or une règle nuancée n'est pas une règle. Le modèle doit trancher, et il tranche différemment à chaque fois.

La stratification fonctionne de la même manière que dans Encore :

# DESIGN.md          <- foundation: tokens, roles, prohibitions
                        applies everywhere, never overridden

# app/marketing/DESIGN.md
   Extends the root. Spacing scale shifted up one step.
   Hero type may use the display scale (48px+).
   Cards may use shadow elevation.

# app/dashboard/DESIGN.md
   Extends the root. Compact spacing (8-12px controls).
   Elevation is surface steps + hairline, never shadow.
   Table rows: 32px, no vertical padding above 8px.

Chaque fichier est sans ambiguïté dans son propre périmètre. La racine ne contient que ce qui ne doit absolument pas varier (rôles de couleurs, famille typographique, interdictions), et les feuilles contiennent les décisions qui diffèrent légitimement. Un agent travaillant dans app/dashboard/ lit deux fichiers et obtient une réponse unique et claire, plutôt qu'un seul fichier truffé de mises en garde.

Nous avons analysé 299 fichiers DESIGN.md publiés pour être lus par des agents. 44 % ne contenaient aucune valeur de taille concrète et 54 % s'appuyaient sur au moins un adjectif vague : « clean » dans 39 % des cas, « moderne » dans 36 %. C'est l'exemple extrême du problème de nuance : un fichier qui ne s'engage jamais sur un chiffre ne peut pas être contradictoire avec lui-même, mais il est incapable de produire une interface cohérente.

Vous n'avez probablement pas 45 plateformes. Vous avez peut-être trois surfaces, dont deux ont divergé discrètement, et une équipe qui demande sans cesse un composant que personne d'autre ne veut. C'est le même problème, à une échelle moindre, et les solutions d'Encore s'appliquent également à ce format.

Placez ce qui ne doit pas varier dans une fondation et rendez-le véritablement non modifiable. Laissez les besoins spécialisés dans des couches spécialisées plutôt que de les forcer dans le cœur du système ou de les en exclure totalement. Lorsqu'une couche est submergée de demandes, cherchez la couche manquante en dessous avant de commencer à refuser. Et concevez pour toutes les surfaces simultanément, car un composant adapté a posteriori est un composant qui divergera.