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: Jede Komponente hat eine Funktion und eine Persönlichkeit, ist durch einen Satz von Eigenschaften definiert und kann mit anderen koexistieren sowie unabhängig evolvieren oder verschwinden. Der genannte Vorteil ist der Verzicht auf ein komplexes Netzwerk aus miteinander vernetzten Einzelteilen.

Dies ist eine Ablehnung von Atomic Design durch ein Team, das über die Ressourcen verfügte, Atomic Design korrekt zu implementieren, und sich bewusst dagegen entschied. 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 Nutzen aus der Wiederverwendbarkeit. Ein System, das iOS, Android, Tablet und Web umfasst, kann dies nicht, da der Atom-Baum in Swift, Kotlin und dem jeweiligen Web-Stack des Jahres identisch reproduziert werden müsste – was in der Praxis nicht geschieht.

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 auf vier Plattformen und in vier Codebasen wissen, ob es sich um die letzte Zeile handelt – auch wenn eine Zeile bedingt ausgeblendet ist. 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), folgt jedoch bei einer kurzen Liste von Punkten bewusst nativen Konventionen: 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 erwähnt, 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 eine 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 Ihr Interface 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, und das ist der Grund, warum dies heute wichtiger ist als damals. Eine plattformübergreifende Drift wird erst nach einem Release-Zyklus sichtbar, und ein Designer bemerkt sie. Eine Agent-Drift tritt innerhalb einer einzigen Session zwischen zwei Dateien auf, und niemand bemerkt sie bis zum dritten Screen.

Wir haben 299 DESIGN.md-Dateien analysiert, die für AI-Agenten veröffentlicht wurden, um zu prüfen, wie viel tatsächlichen Vertrag sie enthalten. 86 % gaben Farben als reine Hex-Werte ohne zugewiesene Rolle an: eine Werteliste, kein Vertrag. 76 % enthielten keinerlei Verbote. 44 % enthielten an keiner Stelle konkrete Größenwerte, und 54 % stützten sich auf mindestens ein vages Adjektiv, am häufigsten „clean“ (39 %) oder „modern“ (36 %).

Eine solche Datei ist das Scheitern von Atomic Design in Textform. Sie liefert Teile ohne Angabe ihres Verwendungszwecks, und jeder Screen, 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 sind dreißig Sekunden Schreibarbeit, und es ist der Unterschied zwischen einem Agenten, der auf Screen vierzehn dieselbe Card produziert, und einem, der eine neue erfindet.

Das DLS steht nicht zur Installation zur Verfügung, und es wäre ohnehin das falsche Ziel, dessen visuelles Ergebnis zu kopieren. Es wurde für einen Reise-Marktplatz entwickelt, bei dem Fotografie der primäre Inhalt ist – ein spezifisches Problem, das die meisten Produkte nicht haben.

Übertragbar sind drei Entscheidungen, deren Umsetzung nichts kostet:

1. Komponenten über Verträge definieren, nicht über Komposition. Schreiben Sie erforderliche Elemente, optionale Elemente und Properties auf. Überlassen Sie die Implementierung den Anforderungen des jeweiligen Zielsystems.
2. Kontextabhängige Visuals in die Komponente verschieben. Die Divider-Regel, generalisiert: Wenn ein Container etwas über seine Kinder wissen muss, um diese korrekt zu rendern, wurde die Logik an der falschen Stelle platziert.
3. Die kurze Liste der Dinge benennen, die divergieren dürfen. Alles andere ist standardmäßig vereinheitlicht. Ein System ohne diese Liste erzwingt entweder eine falsche Parität oder driftet an allen Stellen.

Keine dieser Maßnahmen erfordert ein Designsystem-Team, eine Sketch-Bibliothek oder vier Plattformen. Sie erfordern die Entscheidung, was Ihre Komponenten eigentlich sind – eine Arbeit, die die meisten Systeme auf dem Weg zur Farbauswahl überspringen.