Mal ehrlich: Die meisten Teams, die „Component-Driven Development" betreiben, betreiben es nicht wirklich.
Sie haben Storybook installiert. Vielleicht sogar Chromatic. Ihre Komponenten haben Namen wie Button, Card, Modal. Aber wenn ein neues Feature kommt, fangen sie trotzdem von vorn an. Der nächste Designer muss sich wieder durch Figma-Dateien wühlen. Der neue Developer fragt nach drei Tagen immer noch, welche Button-Variante er nehmen soll.
Das ist kein CDD. Das ist ein Tool-Stack ohne Methodik.
Component-Driven Development ist keine Frage der Tools. Es ist eine fundamentale Entscheidung darüber, wie ein Team Produktentwicklung denkt — von der ersten Pixel-Entscheidung bis zum Live-Deployment. In diesem Artikel zeigen wir, was das konkret bedeutet: den Workflow, die Werkzeuge, die Pitfalls, und warum es sich in Woche 5 bereits rechnet.
Was CDD wirklich ist — und was nicht
Component-Driven Development beschreibt einen Entwicklungsansatz, bei dem UI-Komponenten die kleinste definierte Einheit eines Produkts sind. Nicht Seiten, nicht Features, nicht User Stories. Komponenten.
Der entscheidende Unterschied zu „wir haben Komponenten": Beim CDD-Ansatz werden Komponenten isoliert entwickelt, unabhängig getestet, und erst danach zu vollständigen Seiten zusammengebaut. Nicht andersherum.
Wenn du mit Seiten anfängst, baust du implizit. Dein Button ist plötzlich an drei verschiedenen Stellen leicht anders, weil er drei Mal in verschiedenen Kontexten gebaut wurde. Dein Modal kennt den Zustand der Seite darunter. Deine Karten haben hartcodierte Margins für genau diesen einen Grid-Container. Die Abhängigkeiten wachsen, bis Refactoring aufhört zu laufen und Estimates aufhören zu stimmen.
CDD dreht das um. Du baust klein, dann groß. Du definierst States, bevor du Context kennst. Du zwingst dein Team, in Systemen zu denken.
Der 6-Phasen Workflow
Phase 1: Figma — Die einzige Source of Truth
Alles beginnt in Figma. Aber nicht als Wireframe, nicht als Moodboard. Als strukturierte Komponentenbibliothek mit definierten Varianten und verbundenen Design Tokens.
Was hier entschieden wird, gilt überall. Spacing-Werte, Farbpaletten, Typografie-Skalen — das sind keine Design-Entscheidungen. Das sind Infrastruktur-Entscheidungen. Sie müssen in Figma als Tokens definiert sein, bevor eine Zeile Code geschrieben wird.
Style Dictionary übersetzt diese Tokens später automatisch in CSS Custom Properties, JS-Konstanten und iOS/Android-Assets. Ein Token, alle Plattformen, keine Abweichungen. Das Setup in Figma kostet Zeit — ungefähr einen halben Tag für ein mittelgroßes System. Diese Zeit holst du in Woche 2 zurück.
Phase 2: Storybook — Der isolierte Entwicklungsraum
Jede Komponente lebt zuerst in Storybook. Nicht in einer Next.js-Page, nicht in einem Template. In Storybook.
Das erzwingt eine wichtige Disziplin: Eine Komponente muss ohne ihre Umgebung funktionieren. Sie bekommt ihre Daten über Props. Sie kennt keinen globalen State. Sie kann in jedem Zustand gerendert werden.
Für jeden Komponentenstate gibt es eine Story. Button/Primary, Button/Primary/Disabled, Button/Primary/Loading. Diese Stories sind keine Dokumentation — sie sind Tests. Sie sind Entwicklungsumgebung. Und sie sind das Produktions-Preview für Designer. Wenn ein Designer bei HARWAY Experience eine Änderung sieht, sieht er sie in Storybook, bevor sie live geht.
Phase 3: Chromatic — Visuelles Testing als Standard
Hier scheitern die meisten Teams, weil sie es überspringen. „Wir haben keine Zeit für visuelle Tests." Chromatic fotografiert jede Story bei jedem Build. Es vergleicht Pixel für Pixel mit dem letzten approbierten Snapshot. Wenn sich etwas verändert — ein Schatten, ein Abstand, eine Farbe — stoppt der Build und wartet auf Freigabe.
Das klingt nach Overhead. Tatsächlich: Es sind zwei Klicks pro Review. Und es verhindert die häufigste Art von Production-Bugs: visuelle Regressionen, die kein automatisierter Test jemals findet. Pro Team aus fünf Personen spart Chromatic erfahrungsgemäß zwei bis vier Stunden pro Woche — allein durch wegfallende „Hast du gesehen, dass der Button jetzt komisch aussieht?"-Slack-Nachrichten.
Phase 4: Assembly — Seiten entstehen aus Komponenten
Erst jetzt bauen wir Seiten. Aus verifizierten, isolierten, dokumentierten Komponenten.
Das ist der Moment, an dem CDD seinen eigentlichen Wert zeigt. Ein Page-Template ist keine Designarbeit mehr — es ist Komposition. Du greifst in die Bibliothek, ziehst Komponenten zusammen, und das Resultat ist konsistent, weil die Grundbausteine konsistent sind. Neue Features brauchen neue Komponenten oder neue Varianten bestehender Komponenten. Nichts davon passiert direkt auf der Page.
Phase 5: Versioning — Das System als Produkt behandeln
Ein Design System ist kein Ordner mit Komponenten. Es ist ein Produkt. Es hat Versionen, Changelogs, Breaking Changes, und Consumer — also andere Teams oder Produkte, die davon abhängen.
Turborepo ermöglicht das Management eines Monorepos, in dem das Design System und seine Consumer-Pakete parallel entwickelt werden. Keine Copy-Paste-Dependencies mehr. Keine „welche Version haben wir eigentlich?"-Fragen. Semantic Versioning ist Pflicht: Major für Breaking Changes, Minor für neue Komponenten, Patch für Bug-Fixes.
Phase 6: Analytics — Was Nutzer wirklich tun
Komponenten, die live gehen, sollten gemessen werden. Nicht jede Komponente — aber die kritischen. Wie oft wird eine CTA geklickt? Welche Tab-Variante konvertiert besser? Welcher Error State tritt am häufigsten auf?
Diese Daten informieren die nächste Design-Entscheidung. Der Loop schließt sich: von Analytics zurück in Figma, von Figma durch den Stack. Das System lernt.
Organisatorischer Impact — Was sich wirklich verändert
Designer-Developer Collaboration
In traditionellen Setups handeln Designer und Developer Specs aus. Redlines, Kommentare in Figma, Slack-Threads über Abstände. Das ist langsam und fehleranfällig.
Im CDD-Workflow teilen Designer und Developer eine Sprache: Token-Namen, Komponenten-Namen, Story-Namen. Wenn ein Designer sagt „Button/Primary", weiß der Developer genau, welche Storybook-Story er öffnen soll. Keine Interpretation, kein Raten. Das reduziert die Rückkopplungsschleifen um — je nach Team — 40 bis 60 Prozent. Nicht wegen besserer Kommunikation. Wegen weniger notwendiger Kommunikation.
Onboarding
Ein neuer Developer in einem klassischen Projekt braucht zwei bis vier Wochen, um produktiv zu sein. Er muss die impliziten Regeln lernen, die nie dokumentiert wurden.
In einem CDD-System sind die Regeln explizit: Storybook zeigt alle Komponenten und ihre States. Der Changelog erklärt die Entscheidungsgeschichte. Wir beobachten bei HARWAY Experience, dass Teams mit einem gut gepflegten CDD-System neue Developer in vier bis sieben Arbeitstagen zu produktiven Beiträgen bringen — statt Wochen.
Compounding ROI
Der wirtschaftliche Kern: CDD zahlt sich nicht in Woche 1 aus. Es zahlt sich ab Woche 5 aus — und dann exponentiell.
Ein Design System ohne CDD-Methodik wächst linear — jede neue Komponente kostet ähnlich viel wie die letzte. Ein System mit CDD-Methodik wächst sublinear — die durchschnittlichen Kosten pro Komponente sinken, weil Patterns wiederverwendet werden, Entscheidungen nicht neu getroffen werden, und Qualität als Standard gilt statt als Aufwand.
Die 5 häufigsten Pitfalls — und wie man sie vermeidet
Pitfall 1: Das System bauen, bevor man ein Produkt hat
Das ist der häufigste Fehler bei Startups: „Wir bauen erst das Design System, dann das Produkt." Das Ergebnis: Ein Design System, das abstrakt und unvollständig ist, weil kein reales Produkt die Anforderungen definiert hat. Die Lösung: Das System wächst parallel zum Produkt. Abstraktion kommt durch Wiederholung, nicht durch Planung.
Pitfall 2: Tokens als Afterthought
„Wir fügen die Tokens später hinzu." Nein. Tokens sind die Grundlage. Wenn du sie später hinzufügst, hast du hartcodierte Werte über das gesamte System verteilt, die du nie vollständig findest und ersetzt. Token-Definition passiert in Woche 1, Tag 1. Alles andere ist Technikschulden-Akkumulation.
Pitfall 3: Storybook als Dokumentations-Tool missbrauchen
Storybook ist eine Entwicklungsumgebung. Wenn Teams es ausschließlich als statische Doku-Site nutzen und dort nie entwickeln, verlieren sie den Hauptvorteil: den Zwang zur Isolation. Entwicklung passiert in Storybook, bevor sie in der App passiert. Das ist keine Option, das ist die Methodik.
Pitfall 4: Chromatic-Reviews als Bottleneck behandeln
„Wir haben keine Zeit, visuelle Reviews zu machen." Das ist das falsche Framing. Ein visueller Review dauert zwei Minuten. Eine Production-Regression zu finden und zu fixen dauert zwei Stunden — und kostet Vertrauen. Chromatic-Reviews sind Teil des Pull-Request-Prozesses. Nicht optional.
Pitfall 5: Das System „fertigmachen" wollen
Ein Design System ist nie fertig. Teams, die auf „1.0" warten, bevor sie das System intern verbreiten, bauen in einem Vakuum. Das System muss früh in den echten Workflow eingebaut werden — mit echten Reibungen, echten Feedback-Loops, echten Entscheidungen. Version 0.1 ist besser als Perfektionismus ohne User.
Der 4-Wochen Sprint: Von null auf CDD-Foundation
Woche 1 legt den Token-Layer: Design Tokens in Figma (Farben, Spacing, Typografie), Style Dictionary für Web-Outputs, Storybook mit Theme Provider, Chromatic für erste Snapshots, Turborepo-Monorepo-Struktur. Definition of Done: Tokens sind in Figma, Code und Storybook synchronisiert.
Woche 2 bringt die Basis-Komponenten (Tier 1): mindestens fünf Komponenten vollständig mit Stories für alle States, Accessibility-Grundlagen, Vitest-Tests für interaktive Elemente, erstes Chromatic-Review mit gesetzter Baseline. Definition of Done: Erste Komponenten sind produktionsreif und reviewt.
Woche 3 etabliert den Collaboration-Prozess: erste App-Page aus Storybook-Komponenten zusammengebaut, Designer hat Storybook-Zugang und gibt Feedback, PR-Prozess mit Chromatic-Review-Step, Contributing-Guide geschrieben. Definition of Done: Ein neues Teammitglied kann anhand der Dokumentation selbstständig eine Komponente hinzufügen.
Woche 4 schließt den Loop: Analytics-Integration für kritische CTAs, Dashboard für Komponenten-Usage, Retro über Reibung und Lücken, Roadmap für Woche 5–12. Definition of Done: Das Team hat einen stabilen Rhythmus für System-Weiterentwicklung.
CDD + AI: Agent-assisted Development
Ein CDD-System mit sauber definierten Tokens, klarer Komponentenstruktur und gut gepflegtem Storybook ist nicht nur besser für Menschen — es ist besser für AI-Agents.
Wenn ein Agent wie Claude Code eine Komponente bauen oder erweitern soll, braucht er Kontext. In einem chaotischen Codebase ohne CDD-Methodik antwortet ein Agent mit generischem Code, der nicht ins System passt. In einem gut strukturierten CDD-System kann der Agent direkt auf die Bibliothek zugreifen, Patterns erkennen und konsistente Ergebnisse liefern.
Wir nennen das bei HARWAY Experience „Agent-assisted Component Development". Der Token-Layer steht als strukturierter Kontext zur Verfügung. Storybook-Stories definieren die erwarteten Props-APIs. Chromatic stellt sicher, dass generierter Code visuell konsistent ist. Ein Agent kann neue Komponenten in Minuten erstellen, die ins System passen. Was früher einen halben Tag dauerte, dauert jetzt 45 Minuten. Die Voraussetzung: das System muss stehen.
Das Fundament für alles, was kommt
Diese Serie hat sich mit fünf Aspekten moderner Design-System-Praxis beschäftigt. Wir haben über Token-Architektur gesprochen, über die richtigen Fragen vor dem ersten Sprint, über skalierbare Komponentenhierarchien, und über die Governance-Strukturen, die ein System langfristig am Leben erhalten.
Component-Driven Development ist das Fundament, auf dem alles aufbaut. Ohne CDD-Methodik sind Tokens ein Ordner in Figma. Ist Storybook ein Dokumentationstool, das keiner liest. Ist Chromatic ein Kostenpunkt, der regelmäßig in Frage gestellt wird. Mit CDD-Methodik sind Tokens die einzige Wahrheitsquelle. Ist Storybook der Ort, an dem Entwicklung passiert. Ist Chromatic die Versicherungspolice, die niemand missen will.
Der Unterschied liegt nicht in den Tools. Er liegt in der Entscheidung, wie man arbeitet.
Häufig gestellte Fragen
Ja. Der Ansatz heißt „Strangler Fig Pattern": Neue Komponenten entstehen nach CDD-Methodik. Alte Komponenten werden migriert, wenn sie sowieso angefasst werden müssen. Du brauchst keinen Big-Bang-Rewrite.
