Airbnbs DLS: Das System, das Atomic Design ablehnte

Im veröffentlichten Bericht des Designteams zum DLS wird die grundlegende strukturelle Entscheidung direkt benannt: Anstatt sich auf einzelne Atome zu verlassen, betrachteten sie Komponenten als Elemente eines lebenden Organismus – jeder mit einer Funktion und einer Persönlichkeit, definiert durch einen Satz von Eigenschaften, fähig, mit anderen zu koexistieren und unabhängig zu evolvieren oder zu verschwinden. Der genannte Vorteil ist der Verzicht auf ein komplexes Netzwerk aus miteinander vernetzten Teilen.

Dies ist eine Ablehnung von Atomic Design durch ein Team, das über die Ressourcen verfügt hätte, Atomic Design korrekt zu implementieren, und sich bewusst dagegen entschieden hat. Es lohnt sich, dies ernst zu nehmen, anstatt es als bloße stilistische Präferenz abzutun, da die Argumentation generalisierbar ist.

Generell ist keine der beiden Spalten korrekt. Die richtige Antwort hängt davon ab, welchen Fehlermodus man sich leisten kann. Ein Single-Platform-Webprodukt mit einem kleinen Team kann das Risiko der Fehlerfortpflanzung absorbieren und zieht einen echten Mehrwert aus der Wiederverwendbarkeit. Ein System, das iOS, Android, Tablet und Web umfasst, kann dies nicht, da der Atom-Baum identisch in Swift, Kotlin und dem jeweiligen Web-Stack des Jahres reproduziert werden müsste – was in der Praxis nicht geschehen wird.

Ein Detail aus dem DLS-Bericht erklärt die gesamte Philosophie besser als die Philosophie selbst. Anstatt Trennlinien als eigene Elemente zwischen Komponenten zu führen, muss jede Komponente ihren eigenen Trenner enthalten, der über die View-Logik ein- oder ausgeblendet wird.

Betrachten Sie die Kosten der Alternative. Wenn Trenner zwischen Komponenten liegen, ist die Sichtbarkeit eines Trenners eine Eigenschaft der Liste, nicht der Zeile – die Liste muss also wissen, ob es sich um die letzte Zeile handelt, und zwar auf vier Plattformen, in vier Codebasen, einschließlich der Fälle, in denen eine Zeile bedingt ausgeblendet wird. Jede Listen-Implementierung setzt diese Logik neu um, und eine davon wird es falsch machen. Verschiebt man den Trenner in die Zeile, wird die Regel lokal: Eine Zeile weiß, ob sie ihre eigene Unterkante zeichnet, und keine übergeordnete Ebene muss die Position berechnen.

Im selben Dokument wird vermerkt, dass die Elemente, die jede Komponente definieren, sowohl in der Sketch-Datei als auch im Code deklariert wurden. Das ist die andere Hälfte des Vertrags: Eine Komponente wird nicht durch ihr Rendering auf einer bestimmten Plattform definiert, sondern durch die Liste der Dinge, die sie enthalten muss. Sketch und Swift sind zwei Implementierungen derselben Deklaration.

Das DLS wird als weitgehend plattformagnostisch beschrieben – die meisten Komponenten sehen auf iOS und Android gleich aus und funktionieren identisch –, während es bei einer kurzen Liste von Punkten bewusst nativen Konventionen folgt: Navigation, System-Ikonografie, kontextbezogene Aktionen und Interaktionen. Die Android-Navigationsleiste unterscheidet sich bewusst von der iOS-Leiste und verwendet ein anderes Icon.

Die kurze Liste ist der interessante Teil. Ein System, das eine totale Parität anstrebt, erzeugt eine App, die sich auf beiden Plattformen fremd anfühlt; ein System, das sich überall den Plattformkonventionen beugt, erzeugt zwei Produkte, die lediglich ein Logo gemeinsam haben. Das DLS zieht die Grenze bei den Elementen, die Nutzer vom Betriebssystem und nicht von Ihrem Produkt gelernt haben. Die Zurück-Navigation ist eine OS-Konvention. Eine Preiszeile hingegen nicht.

Im selben Dokument wird vermerkt, dass das System so aufgebaut wurde, dass identischer Code, identische Komponenten und Designs über verschiedene Gerätegrößen hinweg funktionieren, wobei ein kleiner Satz von Layout-Regeln die Transformation für Tablets übernimmt. Das ist dasselbe Prinzip, angewandt auf eine andere Achse: Behalten Sie eine Definition bei und fügen Sie Regeln für die Achse hinzu, die tatsächlich variiert.

Der rote Faden ist, dass die „Unit of Truth“ des DLS eine Deklaration ist, keine Implementierung. Eine Komponente ist ein Name plus einer Liste von erforderlichen Elementen, optionalen Elementen und Verhaltenseigenschaften. Swift, Kotlin, der Web-Build und die Sketch-Library sind vier Renderings dieser Deklaration.

Das ist der Grund, warum dieser Ansatz über Plattformen hinweg skalierte, während ein Atom-Baum-Ansatz dies nicht getan hätte. Ein Vertrag kann durch jede beliebige Implementierung erfüllt werden. Ein Kompositionsbaum kann nur durch die Reproduktion des Baums erfüllt werden – und in dem Moment, in dem das Framework einer Plattform dies erschwert, sucht jemand einen Workaround, und die Systeme forken.

Das ist auch der Grund, warum das Modell auf eine Plattform anwendbar ist, an die 2015 niemand gedacht hat.

Wenn ein Coding-Agent Ihre Benutzeroberfläche schreibt, tut er genau das, was das iOS-Team getan hat: Er rendert Ihr System in einer Umgebung mit eigenen Idiomen und Einschränkungen, basierend auf der Definition, die Sie ihm übergeben haben. Jede Frage, die das DLS beantworten musste, kehrt unverändert zurück.

Die letzte Zeile zeigt den praktischen Unterschied auf, und genau das ist der Grund, warum dies heute wichtiger ist als damals. Ein plattformübergreifender Drift benötigt einen Release-Zyklus, bis er sichtbar wird und ein Designer ihn bemerkt. Agent-Drift tritt innerhalb einer Session auf, zwischen zwei Dateien, und niemand bemerkt es, bis der dritte Bildschirm erscheint.

Wir haben 299 DESIGN.md Dateien analysiert, die für KI-Agenten veröffentlicht wurden, um zu sehen, wie viel Vertrag sie tatsächlich enthalten. 86 % gaben Farben als rohe Hex-Werte ohne zugewiesene Rolle an – eine Werteliste, kein Vertrag. 76 % enthielten keinerlei Verbote. 44 % enthielten nirgendwo konkrete Größenwerte, und 54 % stützten sich auf mindestens ein vages Adjektiv, meistens „clean“ (39 %) oder „modern“ (36 %).

Eine solche Datei ist das Scheitern von Atomic Design in Prosaform. Sie übergibt Teile ohne Angabe dessen, wofür sie gedacht sind, und jeder Bildschirm, den der Agent schreibt, setzt sie anders zusammen. Was das DLS stattdessen geschrieben hätte, wäre eine Deklaration: Diese Komponente benötigt diese Elemente, diese Farbe hat diese Rolle, dies ist nicht erlaubt.

## 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.

Das ist eine dreißigsekündige Schreibarbeit, und es ist der Unterschied zwischen einem Agenten, der auf Bildschirm vierzehn dieselbe Card produziert, und einem, der eine neue erfindet.

Das DLS ist nicht zum Installieren verfügbar, und das visuelle Ergebnis nachzuahmen, wäre ohnehin die falsche Herangehensweise – es wurde für einen Reise-Marktplatz mit Fotografie als primärem Inhalt entwickelt, was ein spezifisches Problem ist, das die meisten Produkte nicht haben.

Was übertragbar ist, sind drei Entscheidungen, deren Übernahme nichts kostet:

1. Definieren Sie Komponenten durch Verträge, nicht durch Komposition. Schreiben Sie erforderliche Elemente, optionale Elemente und Eigenschaften auf. Überlassen Sie die Implementierung dem, was die jeweilige Zielplattform benötigt.
2. Verschieben Sie kontextabhängige Visuals in die Komponente. Die Trennlinien-Regel, verallgemeinert. Wenn ein Container etwas über seine Kinder wissen muss, um sie korrekt darzustellen, haben Sie die Logik an der falschen Stelle platziert.
3. Benennen Sie die kurze Liste der Dinge, die divergieren dürfen. Alles andere ist standardmäßig vereinheitlicht. Ein System ohne diese Liste erzwingt entweder eine falsche Parität oder driftet überall ab.

Keines davon erfordert ein Designsystem-Team, eine Sketch-Library oder vier Plattformen. Es erfordert die Entscheidung, was Ihre Komponenten sind – eine Aufgabe, die die meisten Systeme überspringen, bevor sie mit der Farbauswahl beginnen.