Atomic Design im Zeitalter der Agenten: Was davon noch Bestand hat

Atomic Design schlug vor, Interfaces als Hierarchie zu verstehen: Atome (ein Label, ein Input, ein Button), Moleküle (ein Suchformular), Organismen (ein Site-Header), Templates (Layout auf Seitenebene ohne Inhalt) und Pages (ein Template mit tatsächlichem Inhalt).

Es lohnt sich, den Kontext zu betrachten. 2013 war die meiste Front-End-Arbeit seitenbasiert. Designer lieferten Comps einzelner Seiten; Entwickler bauten einzelne Seiten; derselbe Button existierte in elf leicht unterschiedlichen Formen, und niemand hatte einen Namen für dieses Problem. Atomic Design gab Teams ein gemeinsames Vokabular und, was noch wichtiger war, das Argument, dass Interfaces aus einem System zusammengesetzt werden sollten, anstatt sie Seite für Seite zu zeichnen.

Dieses Argument hat vollständig gesiegt. Jedes komponentenbasierte Framework, jedes Designsystem und jede derzeit verwendete Token-Ebene setzt dies voraus. Wenn Leute sagen, Atomic Design sei tot, meinen sie meist, dass seine Schlussfolgerung zum Standard wurde und seine Terminologie optional wurde – und genau so sieht der Sieg einer Methodik aus.

Die fünf Ebenen sind nicht gleichermaßen nützlich, und die Behauptung, dies sei der Fall, kostet Teams Zeit. Sortiert nach dem Grad der Diskussionen im Verhältnis zum Nutzen:

Die Diskussion über die „Molekül-Zeile“ ist keine bloße Pedanterie. Fragen Sie fünf Engineers, ob eine Karte mit Bild, Titel und Button ein Molekül oder ein Organismus ist, und Sie erhalten eine vierzigminütige Diskussion ohne jegliche praktische Auswirkung. Jede Taxonomie-Ebene, deren Abgrenzung nicht schnell entschieden werden kann und die keinen Einfluss darauf hat, was gebaut wird, ist Overhead.

Es gibt eine fundiertere Kritik als „die Bezeichnungen sind zu kleinteilig“, und sie stammt von einem Team, das über die Ressourcen verfügte, Atomic Design korrekt zu implementieren, sich jedoch dagegen entschied.

Das Design-Team von Airbnb veröffentlichte, dass sie Komponenten nicht auf einzelnen Atomen aufbauten, sondern sie als Elemente eines lebenden Organismus behandelten – jedes mit einer Funktion und Persönlichkeit, definiert durch einen Satz von Properties, fähig zu koexistieren sowie unabhängig zu evolvieren oder zu verschwinden. Der genannte Vorteil war die Vermeidung eines komplizierten Netzwerks miteinander verknüpfter Teile.

Das ist ein echter Trade-off, keine bloße Präferenz:

Keine der beiden Spalten ist generell korrekt. Ein Single-Platform-Webprodukt mit einer Codebasis profitiert massiv von maximaler Wiederverwendbarkeit und kann das Risiko der Propagation tragen. Ein System über vier Plattformen hinweg kann dies nicht, da der Atom-Baum in jeder Plattform identisch reproduziert werden müsste, was in der Praxis nicht geschieht. Airbnb hatte vier Plattformen.

Hier kommt der Teil, der wirklich neu ist und in eine unerwartete Richtung führt.

Der Hauptbeitrag von Atomic Design war ein gemeinsames Vokabular. Es ermöglichte Designern, Engineers und Produktmanagern, auf dasselbe Element zu zeigen und dasselbe zu meinen. Ein Coding-Agent benötigt dies nicht. Er weiß bereits im Detail, was ein Button, eine Karte, eine Navigationsleiste und eine Datentabelle sind – und das über jedes Framework hinweg, das man verwenden mag. Das Benennungsproblem, das Atomic Design löste, existiert für einen Agenten nicht.

Was einem Agenten fehlt, liegt an ganz anderer Stelle:

Die unteren drei Zeilen sind links leer, und das ist keine Kritik an der Methodik — sie hat nie versucht, diese zu füllen. Es ist jedoch ein Grund, nicht zu erwarten, dass sie bei dem aktuellen Problem hilft.

Wir haben 299 DESIGN.md-Dateien analysiert, die Coding-Agenten Design-Richtlinien vorgeben sollten, und diese Leere zeigt sich auch dort. 76 % enthalten keinerlei Verbote. 86 % geben Farben als reine Hex-Werte ohne semantische Rolle an. 57 % definieren keine markanten Motive. 44 % enthalten an keiner Stelle einen konkreten Größenwert, und 54 % verlassen sich auf mindestens ein vages Adjektiv — „clean“ in 39 %, „modern“ in 36 %.

Eine Datei, die tadellos nach Atomen, Molekülen und Organismen organisiert ist, aber nichts davon enthält, wird ein gut strukturiertes, generisches Interface hervorbringen. Die Taxonomie war nie die bindende Einschränkung.

Keine neue Taxonomie. Der richtige Schritt besteht darin, die kompositorische Disziplin beizubehalten — die ohnehin schon vorhanden ist — und die Ebenen hinzuzufügen, die Atomic Design nie abgedeckt hat.

1. 1

   Hierarchie behalten, Diskussion beenden

   Primitives, Komponenten, Layouts. Drei Ebenen, sofort entscheidbar. Wenn sich Ihr Team bereits auf Atome/Moleküle/Organismen geeinigt hat und dies keinen Aufwand verursacht, behalten Sie es bei — die Bezeichnungen sind nicht das Problem, sondern die Diskussionen darüber.

2. 2

   Komponenten über Kontrakte definieren, nicht über Komposition

   Halten Sie erforderliche Elemente, optionale Elemente und Eigenschaften schriftlich fest. „Eine Card benötigt einen Titel und einen unterstützenden Text, optional ein Bild, ein Badge und eine Footer-Aktion.“ Diese Aussage übersteht jede Implementierung, auch eine, die von einem Agenten in einem Framework geschrieben wurde, das Sie nicht vorhergesehen haben.

3. 3

   Die Constraint-Ebene hinzufügen

   Die Liste der Dinge, die niemals getan werden. Keine Gradienten, keine Schatten-Elevation, keine Schriftstärke über 600, keine Farbe außerhalb des Token-Sets. Dies ist die Ebene, die den generierten Output am stärksten beeinflusst und die Ebene, die in den meisten Systemen fehlt.

4. 4

   Die Intentions-Ebene hinzufügen

   Wofür das Design gedacht ist und wer es liest. Ein komplexes Tool für Nutzer, die den ganzen Tag darin arbeiten, und eine Marketingseite, die jemand für vierzig Sekunden scannt, erfordern gegensätzliche Entscheidungen. Keine Komponenten-Hierarchie kodiert, welche der beiden Fälle vorliegt.

Schritt zwei lohnt es sich, zu vertiefen, da dies der Teil ist, der sich am besten auf von Agenten geschriebenen Code übertragen lässt. Ein Kontrakt kann durch jede beliebige Implementierung erfüllt werden; ein Kompositionsbaum kann nur durch die Reproduktion des Baums erfüllt werden. Wenn der Implementierer ein Modell ist, das eine andere Struktur wählen könnte als Sie, bleibt ein Kontrakt stabil, ein Baum hingegen nicht.

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

Neun Zeilen, und jede einzelne ist prüfbar. Beachten Sie, wie viel davon aus Verboten besteht. Dieses Verhältnis ist der Unterschied zwischen einer Spezifikation und einer Beschreibung.

Nein, und diese Fragestellung ist wenig hilfreich. Atomic Design hat das Argument geliefert, dass Interfaces zusammengesetzte Systeme sind. Dieses Argument ist mittlerweile so allgemein akzeptiert, dass es unsichtbar geworden ist — es ist in React, in jedem Design-Tool und in jedem seitdem veröffentlichten Designsystem verankert. Man kann es nicht verwerfen, weil man sich bereits darin befindet.

Was veraltet ist, ist die Vorstellung, dass die Taxonomie das eigentliche Ergebnis ist. Ein System, das in fünf benannte Ebenen unterteilt ist, aber keine Constraints, keine Rollen und keine Intention enthält, ist lediglich ein Ablagesystem. Es wird konsistente, gut strukturierte und völlig austauschbare Interfaces produzieren, was jedoch nie das Ziel war.

Die verbleibende Arbeit ist genau das, was Atomic Design bewusst ausgelassen hat: festzulegen, wofür Ihr Design da ist, was es ablehnt, und beides dort niederzuschreiben, wo das Tool, das Ihr Interface baut, es tatsächlich lesen wird.