Atomic Design — Grundlagen, Atome, Moleküle und Organismen in der UI

Was ist Atomic Design?

Atomic Design ist eine Methodik zur Erstellung hierarchischer Schnittstellensysteme, bei der jedes UI-Element zu einer von fünf Ebenen gehört: Atome (grundlegende Elemente), Moleküle (Kombinationen von Atomen), Organismen (komplexe Blöcke), Vorlagen (Seitendrahtmodelle) und Seiten (spezifische Bildschirme mit Daten). Die Analogie stammt aus der Chemie: Atome verbinden sich zu Molekülen, Moleküle zu Organismen, Organismen zu Vorlagen, Vorlagen werden mit Inhalt gefüllt und werden zu Seiten.

Die Methodik wurde 2013 von Webdesigner Brad Frost als Antwort auf das Problem des "Seitendenkens" vorgeschlagen — bei dem jeder neue Bildschirm ohne Berücksichtigung vorhandener Komponenten von Grund auf neu entworfen wird. In seinem Buch "Atomic Design" (2016) beschreibt Frost die Umsetzung der Methodik in Projekten großer Unternehmen: IBM, GE, Starbucks. Laut Nielsen Norman Group (2022) reduziert Atomic Design die Zeit für das Design neuer Bildschirme um 30–50 % durch die Wiederverwendung fertiger Komponenten.

Atomic Design ist weniger eine Technologie als eine Philosophie der UI-Organisation. Es ist an kein spezifisches Framework gebunden und sowohl im Web (React, Vue) als auch in der mobilen Entwicklung (Jetpack Compose, SwiftUI) anwendbar. Bei IT Sectr verwenden wir Atomic Design, um Designsysteme für Kunden zu erstellen: Wir identifizieren atomare Komponenten in der Designphase und übertragen sie in Code-Komponenten in Compose/SwiftUI.

Fünf Ebenen: Atome, Moleküle, Organismen, Vorlagen, Seiten

Jede Ebene von Atomic Design löst ihr eigenes Problem und hat einen strengen Verantwortungsbereich. Atome sind die kleinsten Bausteine der Schnittstelle, die nicht weiter zerlegt werden können, ohne ihren Sinn zu verlieren: Button, Textfeld, Icon, Label, Checkbox. Atome enthalten keine Geschäftslogik und sind nicht vom Kontext abhängig. Sie definieren grundlegende visuelle Eigenschaften: Farbe, Größe, Abstände, Typografie.

Moleküle sind Kombinationen von zwei oder mehr Atomen, die einfache funktionale Einheiten bilden. Ein Eingabefeld mit Label und Fehlermeldung ist ein Molekül. Eine Produktkarte mit Bild, Name und Preis ist ein Molekül. Moleküle können grundlegende Logik enthalten (Fehler anzeigen/ausblenden), enthalten jedoch keine Geschäftsprozesse. Moleküle sind die erste Ebene, auf der Komponenten über verschiedene Bildschirme hinweg wiederverwendbar werden.

Organismen sind komplexe Schnittstellenblöcke, die aus Molekülen und Atomen bestehen und eine bestimmte Anwendungsfunktion implementieren. Ein Anmeldeformular (E-Mail-Feld, Passwortfeld, Senden-Button, Link "Passwort vergessen") ist ein Organismus. Ein Header mit Logo, Suche und Navigation ist ein Organismus. Organismen können Geschäftslogik enthalten und auf die API zugreifen, jedoch nur innerhalb ihrer Funktion.

Vorlagen sind Seitendrahtmodelle, die die Anordnung der Organismen auf dem Bildschirm ohne spezifischen Inhalt definieren. Eine Vorlage definiert das Raster, Spalten, Inhaltsbereiche — ein Drahtmodell auf Code-Ebene. Vorlagen enthalten keine Daten, nur Platzhalter. Sie ermöglichen die Bewertung der Seitenstruktur vor dem Befüllen mit Inhalt.

Seiten sind spezifische Anwendungsbildschirme, bei denen die Vorlage mit echten Daten gefüllt ist. Auf dieser Ebene wird überprüft, wie Komponenten mit echtem Inhalt aussehen (lange Zeichenfolgen, fehlende Daten, Fehler). Seiten sind die einzige Ebene, die der Endbenutzer sieht. Änderungen auf Seitenebene sollten sich nicht auf Atome, Moleküle und Organismen auswirken — wenn eine Komponente geändert werden muss, erfolgt die Änderung auf ihrer Ebene, und die Seite übernimmt sie automatisch.

Vorteile und Grenzen von Atomic Design

Vorteile von Atomic Design werden beim Skalieren von Schnittstellen deutlich. Eine einheitliche Komponentenbibliothek gewährleistet visuelle Konsistenz: Ein Button sieht auf allen Bildschirmen gleich aus, weil es dasselbe Atom ist. Laut Brad Frost (2016) reduzieren Unternehmen, die Atomic Design implementiert haben, die Zeit für die Entwicklung neuer Bildschirme um 30–50 % durch die Wiederverwendung fertiger Moleküle und Organismen.

Grenzen — Atomic Design beschreibt nicht, wie der Anwendungszustand verwaltet wird. Die Methodik beantwortet nur die Frage "wie organisiert man UI-Komponenten", befasst sich jedoch nicht mit Geschäftslogik, Routing oder Datenverwaltung. Die zweite Einschränkung ist die Schwierigkeit, Grenzen zu definieren: Wo endet ein Molekül und wo beginnt ein Organismus? In der Praxis sind die Grenzen fließend, und verschiedene Teams können dieselbe Komponente unterschiedlich klassifizieren. Es wird empfohlen, Regeln in Design-Tokens und einem Komponentenkatalog (Storybook, Jetpack Compose Preview) festzulegen.

Die dritte Einschränkung ist übermäßige Abstraktion für kleine Projekte. Wenn eine Anwendung aus 5 Bildschirmen besteht, ist die Erstellung einer Hierarchie von Atomen und Molekülen unnötige Arbeit. Atomic Design wird vorteilhaft, wenn die Anzahl der Bildschirme 20 übersteigt und Komponenten auf verschiedenen Seiten wiederverwendet werden.

Atomic Design vs Feature-Sliced Design

Atomic Design und Feature-Sliced Design (FSD) lösen unterschiedliche Probleme und können zusammen verwendet werden. Atomic Design ist eine Methodik zur Organisation von UI-Komponenten, FSD ist eine Methodik zur Organisation von Geschäftsebenen und der Anwendung als Ganzes. Atomic Design beantwortet die Frage "wie zerlegt man die UI in wiederverwendbare Teile", FSD beantwortet "wie organisiert man Code um Geschäftsfunktionen herum". Sie konkurrieren nicht: Man kann eine FSD-Struktur mit Features- und Entities-Ebenen haben und innerhalb jeder Ebene Atomic Design zur Organisation der UI-Komponenten verwenden.

Typische Kombination: FSD definiert die modulare Struktur der Anwendung (Ebenen, Slices), Atomic Design definiert die interne Struktur der UI-Komponenten innerhalb jedes Slices. Beispielsweise enthält der Slice feature.auth Moleküle (LoginForm, PasswordInput) und Organismen (AuthPage), die nach den Regeln von Atomic Design zusammengesetzt sind. Die Shared-Ebene enthält Atome (Button, Input, Label), die in allen Funktionen wiederverwendet werden.

Atomic Design in mobilen Anwendungen: Compose und SwiftUI

Jetpack Compose und SwiftUI unterstützen die Atomic-Design-Hierarchie auf natürliche Weise durch Komponentenkomposition. Atome in Compose sind grundlegende @Composable-Funktionen: AppButton, AppTextField, AppCheckbox. Jede Funktion akzeptiert Anpassungsparameter (Farbe, Größe, Zustand) und enthält keine Geschäftslogik. Atome werden in der Shared-Ebene definiert und als UI-Kit exportiert.

Moleküle sind @Composable-Funktionen, die mehrere Atome kombinieren: LabeledTextField (Label + Eingabefeld + Fehlermeldung), ProductCard (Bild + Name + Preis). Moleküle können grundlegende Zustände (Feldgültigkeit) enthalten, greifen jedoch nicht auf die API oder ViewModel zu. Sie werden in verschiedenen Organismen wiederverwendet.

Organismen sind @Composable-Funktionen auf Funktionsebene: LoginForm (LabeledTextField für E-Mail + LabeledTextField für Passwort + Senden-AppButton + Wiederherstellungslink). Organismen arbeiten über Intent-Funktionen mit der ViewModel zusammen und können Geschäftslogik enthalten. In SwiftUI wird eine ähnliche Hierarchie durch @ViewBuilder und benutzerdefinierte View-Strukturen aufgebaut.

In SwiftUI ist ein Atom eine benutzerdefinierte View-Struktur AppButton, ein Molekül ist ein Eingabefeld mit Label auf HStack, ein Organismus ist ein Anmeldeformular. Diese Struktur ermöglicht die Wiederverwendung von Komponenten auf allen Bildschirmen — die Änderung eines Atoms (Button-Farbe) wird automatisch auf alle Bildschirme angewendet. Die Kombination von Atomic Design mit einem Designsystem gewährleistet Schnittstellenkonsistenz ohne manuelle Kontrolle jedes Bildschirms.