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. Im Jahr 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 für eine Methodik aus.

Die fünf Ebenen sind nicht gleichermaßen nützlich, und die Behauptung, dies seien sie, kostet Teams Zeit. Sortiert nach dem Grad der Diskussionen pro Einheit an Mehrwert:

Die Diskussion über die „Molekül-Zeile“ ist keine bloße Pedanterie. Fragt man fünf Engineers, ob eine Karte mit Bild, Titel und Button ein Molekül oder ein Organismus ist, führt dies zu einem vierzigminütigen Gespräch 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 aber bewusst 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: Jede Komponente hat eine Funktion und eine Persönlichkeit, wird durch einen Satz von Properties definiert und kann koexistieren sowie unabhängig evolvieren oder verschwinden. Der genannte Vorteil war die Vermeidung eines komplexen 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 dieselbe Sache 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 verwendet. 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 war nie darauf ausgelegt, sie zu füllen. Es ist ein Grund, nicht zu erwarten, dass sie bei dem aktuellen Problem hilft.

Wir haben 299 DESIGN.md Dateien untersucht, die geschrieben wurden, um Agenten Design-Anleitungen zu geben, und die Leere zeigt sich auch dort. 76 % enthalten keinerlei Verbote. 86 % geben Farben als rohe Hex-Werte ohne semantische Rolle an. 57 % definieren keine markanten Motive. 44 % enthalten nirgendwo 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 keines von dem enthält, wird eine gut strukturierte, generische Benutzeroberfläche erzeugen. Die Taxonomie war nie die bindende Einschränkung.

Nicht eine neue Taxonomie. Der nützliche Schritt besteht darin, die kompositorische Disziplin beizubehalten, die ohnehin jeder besitzt, und die Ebenen hinzuzufügen, die Atomic Design nie abgedeckt hat.

1. 1

   Behalten Sie die Hierarchie bei, lassen Sie die Debatte sein

   Primitives, Komponenten, Layouts. Drei Ebenen, sofort entscheidbar. Wenn Ihr Team sich bereits auf Atome/Moleküle/Organismen geeinigt hat und es nichts kostet, behalten Sie es bei. Die Labels sind nicht das Problem, die Diskussion darüber.

2. 2

   Definieren Sie Komponenten durch Verträge, nicht durch Komposition

   Schreiben Sie erforderliche Elemente, optionale Elemente und Eigenschaften auf. „Eine Card benötigt einen Titel und einen Begleittext, 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

   Fügen Sie die Constraint-Ebene hinzu

   Die Liste der Dinge, die niemals getan werden dürfen. Keine Verläufe, keine Schatten-Elevation, keine Schriftstärke über 600, keine Farben außerhalb des Token-Sets. Dies ist die Ebene, die den generierten Output am stärksten verändert, und die Ebene, die die meisten Systeme nicht besitzen.

4. 4

   Fügen Sie die Intent-Ebene hinzu

   Wozu das Design dient und wer es liest. Ein präzises Werkzeug für Menschen, die den ganzen Tag darin arbeiten, und eine Marketing-Seite, die jemand für vierzig Sekunden scannt, erfordern entgegengesetzte Entscheidungen, und keine Komponenten-Hierarchie kodiert, für welchen Fall man sich entscheidet.

Schritt zwei ist es wert, vertieft zu werden, da dies der Teil ist, der sich am besten auf agentengeschriebenen Code übertragen lässt. Ein Vertrag ist von jeder Implementierung erfüllbar; ein Kompositionsbaum kann nur erfüllt werden, indem man den Baum exakt reproduziert. Wenn der Implementierer ein Modell ist, das möglicherweise eine andere Struktur wählt als Sie, hält ein Vertrag stand, 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 überprüfbar. Beachten Sie, wie viel davon aus Verboten besteht. Dieses Verhältnis ist der Unterschied zwischen einer Spezifikation und einer Beschreibung.

Nein, und die Einordnung ist unhilfreich. Atomic Design hat das Argument vorgebracht, dass Benutzeroberflächen zusammengesetzte Systeme sind. Dieses Argument ist mittlerweile so gründlich akzeptiert, dass es unsichtbar ist. Es ist in React eingebaut, in jedem Design-Tool, in jedem Designsystem, das seitdem veröffentlicht wurde. Sie können es nicht verwerfen, weil Sie bereits darin leben.

Abgelaufen ist die Vorstellung, dass die Taxonomie das Lieferobjekt ist. Ein System, das in fünf benannten Ebenen organisiert ist und keine Constraints, keine Rollen und keine Absichtserklärung enthält, ist ein Ablagesystem. Es wird konsistente, gut strukturierte, völlig austauschbare Oberflächen erzeugen, was nie das Ziel war.

Die Arbeit, die bleibt, ist die Arbeit, die Atomic Design bewusst ausgelassen hat: zu entscheiden, wofür Ihr Design gedacht ist, was es nicht tun darf, und beides dort aufzuschreiben, wo das Tool, das Ihre Oberfläche baut, es tatsächlich lesen wird.