Component-Driven Design: Wie ich in Figma denke, bevor ich code

Es gibt einen Moment in der Designarbeit, der die Spreu vom Weizen trennt. Nicht der Moment, in dem das erste Frame aussieht wie etwas. Sondern der Moment, in dem man anfängt, in Systemen statt in Screens zu denken.

Component-Driven Design ist kein Framework. Es ist eine Denkweise.

Was Component-Driven Design bedeutet

Der Kern ist simpel: Bevor du einen Screen designst, definierst du die Bausteine. Nicht das fertige Mosaikbild – die einzelnen Steine.

In der Praxis bedeutet das: Welche UI-Elemente tauchen mehrfach auf? Wie variieren sie? Welche States brauchen sie? Ein Button ist nicht ein Button – er ist eine Komponente mit primärem, sekundärem, destruktivem und disabled State, mit Hover und Active, mit und ohne Icon, mit unterschiedlichen Größen.

Wer das in Figma sauber definiert, bevor er Screens baut, hat hinterher weniger Arbeit, konsistentere Ergebnisse – und ein Handoff-Dokument, das Entwickler lieben.

Warum das für das finale Produkt entscheidend ist

React, Vue, Angular – moderne Frontend-Frameworks denken in Komponenten. Ein gut aufgebautes Figma-File, das dieselbe Logik abbildet, übersetzt sich nahezu 1:1 in saubere Codestruktur.

Was im Design eine Komponente ist, wird im Code eine Komponente. Was im Design eine Variante ist, wird im Code ein Prop. Diese Parallelität spart Entwicklungszeit, reduziert Missverständnisse im Handoff und ergibt ein konsistenteres Endprodukt.

Das Gegenteil – Screens voller hartcodierter, nicht-wiederverwendbarer Elemente – produziert im Code dasselbe: schwer wartbare, schwer erweiterbare Implementierungen.

Wie ich das in der Praxis umsetze

Schritt 1: Inventur machen. Bevor ich anfange zu designen, liste ich alle UI-Elemente auf, die ich erwarte: Navigation, Buttons, Inputs, Cards, Modals, Tabellen, Badges. Was kommt mehrfach vor? Was hat States?

Schritt 2: Atome zuerst. Kleine, wiederverwendbare Elemente zuerst bauen. Button, Input, Badge, Icon. Dann daraus Molecules zusammensetzen: Form, Card, Dropdown. Dann Organisms: Header, Sidebar, Modal.

Das ist im Kern Atomic Design – und es funktioniert, weil es erzwingt, von unten nach oben zu denken statt von oben nach unten.

Schritt 3: States und Variants definieren. Jede Komponente hat mindestens: Default, Hover, Active, Disabled. Viele haben mehr: Error, Loading, Empty, Selected. Diese States in Figma als Varianten zu bauen ist Arbeit – aber diese Arbeit zahlt sich in jedem Review und jedem Handoff aus.

Schritt 4: Erst dann Screens. Wenn die Komponenten-Bibliothek steht, baut sich ein Screen schnell zusammen. Wie Lego. Und jede Änderung an einer Komponente wirkt sich automatisch auf alle Screens aus.

Was das mit Vibe Coding zu tun hat

Wenn ich heute mit Cursor und Claude baue, ist ein gut strukturiertes Figma-File mein wichtigstes Asset. Ich kann eine Komponente beschreiben, weil ich sie in Figma bereits klar definiert habe – mit allen States, allen Variants, allen Maßen.

Der Code-Output ist besser, wenn die Design-Spezifikation präzise ist. Component-Driven Design ist nicht nur eine Designer-Praxis. Es ist der beste Weg, AI-gestütztes Development vorzubereiten.

---

Ihr wollt euer Figma-Setup so strukturieren, dass Handoffs reibungsloser und Entwicklungszyklen schneller werden? Das schauen wir uns gerne gemeinsam an – meldet euch.