Analyse indépendante basée sur les récits publics de l'équipe de design d'Airbnb, écrite pour les personnes créant leurs propres systèmes. Identity Forge n'est pas affilié à Airbnb et n'est pas approuvé par celui-ci. Airbnb et son logo sont des marques déposées de leur propriétaire.
La décision que tout le monde ignore
Dans le récit publié par l'équipe de design sur le DLS, le choix structurel fondateur est énoncé directement : au lieu de s'appuyer sur des atomes individuels, ils ont considéré les composants comme des éléments d'un organisme vivant — chacun ayant une fonction et une personnalité, définis par un ensemble de propriétés, capables de coexister avec d'autres et d'évoluer ou de disparaître indépendamment. L'avantage annoncé est l'absence d'un réseau complexe de pièces interconnectées.
C'est un rejet de l'atomic design, opéré par une équipe qui avait les ressources pour l'implémenter correctement et a choisi de ne pas le faire. Il convient de prendre cela au sérieux plutôt que d'y voir une préférence stylistique, car le raisonnement est généralisable.
| Composition atomique | Organisme autonome | |
|---|---|---|
| Un composant est | Un assemblage de composants plus petits et partagés | Une unité avec des éléments requis et optionnels déclarés |
| Modifier un bouton partagé | Se propage partout, y compris dans des endroits non vérifiés | Modifie le bouton. Chaque composant possède sa propre présentation |
| Réutilisation | Maximale — c'est tout l'intérêt | Délibérée, au niveau du composant |
| Duplication | Minimale | Certaine, acceptée comme le prix de l'indépendance |
| Multiplateforme | Difficile. L'arbre d'atomes doit être identique sur chaque plateforme | Plus facile. Seul le contrat doit correspondre |
| Mode de défaillance | Une modification casse silencieusement quatre interfaces | Deux composants divergent car personne ne l'a remarqué |
En général, aucune des deux colonnes n'est correcte. La bonne réponse dépend du mode de défaillance que vous pouvez tolérer. Un produit web mono-plateforme avec une petite équipe peut absorber le risque de propagation et tire une réelle valeur de la réutilisation. Un système s'étendant sur iOS, Android, tablette et web ne le peut pas, car l'arbre d'atomes doit être reproduit à l'identique en Swift, en Kotlin et dans quelle que soit la stack web de l'année — et ce ne sera pas le cas.
La règle du séparateur
Un détail du récit du DLS explique mieux toute la philosophie que la philosophie elle-même. Plutôt que d'avoir des lignes de séparation existant comme des éléments propres entre les composants, chaque composant doit contenir son propre séparateur, affiché ou masqué par la logique de vue.
Considérez le coût de l'alternative. Si les séparateurs vivent entre les composants, alors l'apparition d'un séparateur est une propriété de la liste, et non de la ligne — la liste doit donc savoir s'il s'agit de la dernière ligne, sur quatre plateformes, dans quatre bases de code, y compris dans le cas où une ligne est masquée conditionnellement. Chaque implémentation de liste réimplémente cette logique et l'une d'elles finit par se tromper. Placez le séparateur à l'intérieur de la ligne et la règle devient locale : une ligne sait si elle doit dessiner sa propre bordure inférieure, et aucun élément supérieur n'a besoin de raisonner sur la position.
La règle généralisable : lorsqu'une propriété visuelle dépend du contexte, poussez-la dans le composant et donnez au composant un moyen d'être informé de son contexte. Ne forcez pas chaque conteneur à réimplémenter la même condition. C'est l'une des rares décisions de design system qui est presque toujours la bonne.
Le même document note que les éléments définissant chaque composant étaient déclarés à la fois dans le fichier Sketch et dans le code. C'est l'autre moitié du contrat : un composant n'est pas défini par son rendu sur une plateforme donnée, mais par la liste des éléments qu'il doit contenir. Sketch et Swift sont deux implémentations d'une même déclaration.
Agnostique vis-à-vis des plateformes, avec des exceptions nommées
Le DLS est décrit comme étant largement agnostique vis-à-vis des plateformes — la plupart des composants ont le même aspect et fonctionnent de la même manière sur iOS et Android — tout en suivant délibérément les conventions natives sur une courte liste d'éléments : la navigation, l'iconographie système, les actions contextuelles et les interactions. La barre de navigation Android diffère de celle d'iOS et utilise une icône différente, par conception.
C'est cette courte liste qui est intéressante. Un système qui recherche une parité totale produit une application qui semble étrangère sur les deux plateformes ; un système qui s'en remet aux conventions de la plateforme partout produit deux produits qui ne partagent qu'un logo. Le DLS trace la ligne au niveau des éléments que les utilisateurs ont appris via le système d'exploitation plutôt que via votre produit. La navigation de retour est une convention de l'OS. Une ligne de tarification ne l'est pas.
| Appartient à la plateforme | Appartient à votre système | |
|---|---|---|
| Exemples | Navigation retour/haut, affordance de partage, icônes système, physique du défilement, menus contextuels, comportement du clavier | Rôles de couleurs, échelle typographique, espacement, composition des composants, structure du contenu, personnalité du mouvement |
| Pourquoi | Les utilisateurs l'ont appris via l'OS, pas via vous. Le modifier leur coûte un effort | Les utilisateurs l'apprennent via vous. Diverger vous coûte un effort |
| Si vous vous trompez | L'application semble subtilement hostile et personne ne sait pourquoi | L'application donne l'impression de provenir de deux entreprises différentes |
Le même document note que le système a été conçu pour que le code, les composants et les designs identiques fonctionnent sur différentes tailles d'appareils, avec un petit ensemble de règles de mise en page gérant la transformation pour tablette. C'est le même principe appliqué à un axe différent : conserver une seule définition, ajouter des règles pour l'axe qui varie réellement.
Pourquoi un contrat survit à la traduction
Le fil conducteur de tout cela est que l'unité de vérité du DLS est une déclaration, pas une implémentation. Un composant est un nom associé à une liste d'éléments requis, d'éléments optionnels et de propriétés comportementales. Swift, Kotlin, le build web et la bibliothèque Sketch sont quatre rendus de cette déclaration.
C'est pourquoi cette approche a pu passer à l'échelle sur plusieurs plateformes, alors qu'une approche par arbre d'atomes n'aurait pas pu. Un contrat peut être satisfait par n'importe quelle implémentation. Un arbre de composition ne peut être satisfait qu'en reproduisant l'arbre, et dès qu'un framework de plateforme rend cela complexe, quelqu'un trouve un contournement et les systèmes divergent.
Un contrat peut être satisfait par n'importe quelle implémentation. Un arbre de composition ne peut être satisfait qu'en reproduisant l'arbre.
C'est également pourquoi ce modèle s'applique à une plateforme à laquelle personne ne pensait en 2015.
L'agent est une autre plateforme
Lorsqu'un agent de code écrit votre interface, il fait exactement ce que l'équipe iOS a fait : rendre votre système dans un environnement avec ses propres idiomes et contraintes, à partir de la définition que vous lui avez fournie. Chaque question que le DLS a dû trancher revient inchangée.
| DLS multiplateforme | Système orienté agent | |
|---|---|---|
| Qu'est-ce qui est unifié ? | Contrat du composant, tokens, structure | Rôles de couleurs, échelle typographique, espacement, interdictions, motifs |
| Qu'est-ce qui est spécifique à la plateforme ? | Navigation, icônes système, actions contextuelles | Framework, bibliothèque de composants, structure des fichiers, syntaxe des classes |
| Lieu de définition | Bibliothèque Sketch et code, synchronisés par une équipe | Un fichier dans le dépôt lu par l'agent |
| Manifestation de la divergence | Deux applications qui semblent provenir d'entreprises différentes | Deux écrans d'une même application qui semblent provenir d'entreprises différentes |
La dernière ligne illustre la différence concrète, et c'est pourquoi l'enjeu est plus crucial aujourd'hui qu'auparavant. Une dérive multiplateforme met un cycle de release à apparaître, et un designer s'en aperçoit. La dérive d'un agent apparaît en une seule session, entre deux fichiers, et personne ne la remarque avant le troisième écran.
Nous avons analysé 299 fichiers DESIGN.md publiés pour être lus par des agents IA, afin de voir quelle part de contrat ils contiennent réellement. 86 % spécifiaient les couleurs sous forme de valeurs hexadécimales brutes sans rôle associé : une liste de valeurs, pas un contrat. 76 % ne contenaient aucune interdiction. 44 % ne mentionnaient aucune valeur de taille concrète, et 54 % s'appuyaient sur au moins un adjectif vague, le plus souvent « clean » (39 %) ou « moderne » (36 %).
Un tel fichier est l'échec de l'atomic design sous forme textuelle. Il livre des pièces sans préciser leur utilité, et chaque écran généré par l'agent les réassemble différemment. À l'inverse, le DLS aurait rédigé une déclaration : ce composant requiert ces éléments, cette couleur a ce rôle, ceci est interdit.
## Card
Required: title, supporting text
Optional: image, badge, footer action
Contains its own bottom divider; hidden when last in a list.
Padding: 16px. Radius: 12px. Border: 1px --border-subtle.
Never uses a drop shadow — elevation is a surface step.
Never uses the accent colour for its border or background.Cela représente trente secondes d'écriture, et c'est ce qui fait la différence entre un agent qui produit la même carte à l'écran quatorze et un autre qui en invente une nouvelle.
Les kits de design d'Identity Forge sont conçus comme ce type de contrat — rôles sémantiques des couleurs, liste explicite des choses à faire et à ne pas faire, motifs et règles de mise en page — et se sérialisent en un fichier DESIGN.md lisible par tout agent de code. Parcourez les kits ou commencez par ce qu'est un fichier DESIGN.md.
Ce qu'il vaut la peine de copier, et ce qu'il ne faut pas
Le DLS n'est pas disponible à l'installation, et chercher à reproduire son rendu visuel serait un mauvais exercice : il a été conçu pour une place de marché de voyage où la photographie est le contenu principal, un problème spécifique que la plupart des produits n'ont pas.
Ce qui est transférable, ce sont trois décisions, dont l'adoption ne coûte rien :
- Définissez les composants par contrat, pas par composition. Listez les éléments requis, les éléments optionnels et les propriétés. Laissez l'implémentation s'adapter aux besoins de chaque cible.
- Intégrez les visuels dépendants du contexte dans le composant. C'est la règle du séparateur, généralisée. Si un conteneur doit connaître des détails sur ses enfants pour les rendre correctement, c'est que la logique est placée au mauvais endroit.
- Nommez la courte liste des éléments autorisés à diverger. Tout le reste est unifié par défaut. Un système sans cette liste impose soit une parité artificielle, soit une dérive généralisée.
Rien de tout cela ne nécessite une équipe de design system, une bibliothèque Sketch ou quatre plateformes. Cela demande simplement de décider ce que sont vos composants, un travail que la plupart des systèmes négligent pour passer directement au choix des couleurs.
Puis-je télécharger ou installer le design system d'Airbnb ?
Non. Le DLS n'est publié ni comme package installable, ni comme site de documentation public. Ce qui est disponible, ce sont les récits écrits de l'équipe de design sur sa construction, ainsi que des reconstructions Figma tierces qui sont des interprétations individuelles plutôt que des spécifications.
Pourquoi Airbnb a-t-il rejeté l'atomic design ?
Leur raisonnement publié était que le fait de traiter les composants comme des assemblages d'atomes partagés crée un réseau complexe de pièces interconnectées. Traiter chaque composant comme une unité autonome avec des éléments requis et optionnels définis permet aux composants d'évoluer ou d'être supprimés indépendamment — ce qui est bien plus important quand le même système doit exister en Swift, Kotlin et en code web.
L'atomic design est-il donc erroné ?
Non, c'est un arbitrage différent. La composition atomique minimise la duplication et convient parfaitement à un produit mono-plateforme avec une seule base de code. En contrepartie, vous acceptez un risque de propagation et une fidélité multiplateforme moindre. Airbnb avait quatre plateformes et a choisi l'autre option. Choisissez en fonction du type d'échec que vous pouvez absorber.
Qu'est-ce qui doit rester identique entre les plateformes et qu'est-ce qui doit différer ?
Gardez vos rôles de couleurs, votre échelle typographique, vos espacements, vos contrats de composants et votre structure de contenu identiques partout. Laissez la plateforme gérer ce que les utilisateurs ont appris via le système d'exploitation plutôt que via votre produit : la navigation retour, l'iconographie système, les fonctions de partage, les menus contextuels, ainsi que le comportement du défilement et du clavier.
Comment cela s'applique-t-il aux agents de code IA ?
Un agent est une plateforme supplémentaire qui rend votre système dans un idiome qui lui est étranger. Il a besoin de la même chose qu'une équipe native : un contrat précisant ce que chaque composant requiert, à quoi sert chaque couleur et ce qui est interdit. La plupart des guides de design écrits pour les agents sont de simples listes de valeurs, c'est pourquoi le rendu diverge d'un écran à l'autre.