Design-Tokens verstehen — Die Grundlage deines Systems
Farben, Abstände und Typografie als zentrale Variablen. Wie du Tokens definierst…
Zum ArtikelKomponenten strukturieren — Organisation deiner Bibliothek
Buttons, Cards, Forms und mehr. Wie du deine Komponenten hierarchisch organisierst, namensgebst und dokumentierst.
Warum Struktur von Anfang an zählt
Die beste Komponentenbibliothek ist nutzlos, wenn dein Team nicht weiß, wo was zu finden ist. Es’s nicht nur um Ordnung — es’s um Geschwindigkeit, Konsistenz und echte Zusammenarbeit.
Ohne klare Struktur passiert das Gleiche wie in einer Garage ohne Regale: Alle Werkzeuge sind da, aber niemand findet das Richtige. Und wenn dein Designer in Figma 20 Minuten sucht, während ein anderer das Button-Element selbst neu erstellt — ja, das ist echtes Geld, das du verschwendest.
In diesem Guide zeigen wir dir, wie du deine Komponenten so organisierst, dass dein Team produktiv bleibt und keine Zeit mit Suchen verschwendet.
Die Basis: Hierarchische Ordnung
Fang mit einer klaren Hierarchie an. Nicht einfach alle Komponenten in einer flachen Liste nebeneinander werfen — das funktioniert nicht skalierbar.
Statt dessen denk in Kategorien: Basis-Komponenten (Button, Input, Label) Zusammengesetzte Komponenten (Form-Feld, Search-Box) Pattern & Seiten-Vorlagen (Login-Form, Produktseite). Jede Ebene baut auf der anderen auf.
Das macht es möglich, dass ein Junior-Designer schnell das richtige Element findet, während Senior-Designer komplexere Pattern aufbauen können. Und dein System wächst mit dir mit, nicht gegen dich.
- Level 1: Primitive (Button, Input, Icon)
- Level 2: Composed (Button + Icon, Form-Field)
- Level 3: Patterns (Search-Bar, Modal, Sidebar)
Namensgebung: Konsistenz schlägt Kreativität
Deine Komponenten-Namen sind wie Variablennamen im Code. Wenn jeder Developer seine eigene Konvention nutzt, wird’s zum Chaos.
Wir empfehlen ein einfaches Schema:
[Komponenten-Typ]-[Variant]-[Status]
Zum Beispiel: Button-Primary-Default , Button-Secondary-Hover , Card-Featured-Dark . Das ist selbsterklärend. Jeder versteht sofort, was gemeint ist — auch ohne lange Dokumentation zu lesen.
Größer wird’s bei zusammengesetzten Komponenten. Ein Form-Field könnte sein: FormField-TextInput-Error oder FormField-Select-Disabled . Die Struktur bleibt gleich, nur die Details ändern sich.
Praktische Organisation in deinem Design-Tool
In Figma (oder Sketch, XD — egal welches Tool) nutzt du am besten die Komponenten-Seite als dein System. Nicht versteckt irgendwo auf Page 47.
Erstelle eine dedizierte Komponenten-Seite mit klarer Struktur. Gruppiere sie nach Kategorie. Button-Komponenten zusammen, Form-Komponenten zusammen, Card-Komponenten zusammen. Innerhalb jeder Gruppe: Variant neben Variant.
Nutze auch die Main Component + Component Instances Struktur richtig. Die Main Component ist deine Quelle der Wahrheit. Alle Designs im Projekt verwenden nur Instances davon — so garantierst du, dass Änderungen sich überall auswirken.
Ein praktischer Tipp: Erstelle auch eine Übersichtsseite mit Screenshots aller Komponenten + ihre Namen. Das ist wie ein Inhaltsverzeichnis — neuen Team-Mitgliedern hilft’s enormig beim Einstieg.
Dokumentation: Dein System wird gelebt
Schöne Komponenten sind nutzlos ohne Dokumentation. Echt. Wenn dein Developer nicht weiß, welche Props ein Button hat oder in welchen Situationen man die Secondary-Variant nutzt — werden die Komponenten nicht genutzt.
Du brauchst nicht viel. Aber du brauchst es. Für jede Komponente dokumentieren: Was macht sie? (Beschreibung) Wann nutze ich sie? (Use Cases) Was sind die Varianten? (Größen, States, Farben) Gibt’s besondere Regeln? (Accessibility, Performance)
Tools wie Storybook (für React/Vue), Zeroheight oder einfach ein Google Doc — die Technologie ist egal. Wichtig ist: Es’s leicht zu finden, leicht zu lesen und es wird aktuell gehalten.
Und ja, dein Team wird die Dokumentation updaten, wenn du es zu einer Gewohnheit machst. Wenn neue Komponenten-Variante sofort dokumentiert wird (nicht “später”). Das verhindert, dass Dokumentation veraltet.
Best Practices: Was andere richtig machen
Konsistente Namenskonvention
Einmal definieren, immer befolgen. Dein Team wird dir danken, wenn alle Button-Komponenten Button heißen (nicht “Btn” oder “ActionButton”).
Klare Hierarchie-Struktur
Basis Composed Patterns. Jede Ebene baut logisch auf der vorherigen auf. Das macht dein System wartbar und skalierbar.
Lebendige Dokumentation
Dokumentation, die nicht aktuell ist, ist schlimmer als gar keine. Build Update-Dokumentation in deinen Design-Prozess ein.
Verlinkung zwischen Tools
Figma-Komponenten Dokumentation Code-Repository. Wenn alles miteinander verlinkt ist, findet jeder schnell was er braucht.
Ownership definieren
Wer ist verantwortlich für welche Komponenten-Familie? Das verhindert, dass niemand sich zuständig fühlt.
Versionierung
Wenn eine Komponente sich ändert, welche Projekte sind betroffen? Mit Versionierung weißt du, wer updaten muss.
Die wichtigsten Punkte zusammengefasst
Eine gut strukturierte Komponentenbibliothek ist die Grundlage für schnelle, konsistente Design-Arbeit. Du brauchst nicht viel mehr als:
- Hierarchische Ordnung: Primitive Composed Patterns
- Klare Namenskonvention: [Typ]-[Variant]-[Status] oder ähnlich
- Dedizierte Komponenten-Seite: Alles zentral an einem Ort
- Aussagekräftige Dokumentation: Was, wann, wie — kurz und prägnant
- Regelmäßige Wartung: Komponenten und Doku zusammen updaten
Dein Team wird produktiver. Neue Features sind schneller gebaut. Und dein Design System bleibt nicht nur schön, sondern wird auch wirklich genutzt. Das ist der Unterschied zwischen einem System, das existiert, und einem, das lebt.
Bereit, dein System neu zu strukturieren? Fang mit einer Kategorie an, dokumentiere sie, und lass dein Team Feedback geben. Kleine Verbesserungen über Zeit schlagen eine perfekte Struktur, die keiner versteht.
Zurück zu Design-System & KomponentenVerwandte Artikel
Hinweis zum Inhalt
Dieser Artikel bietet allgemeine Richtlinien und Best Practices zur Organisation von Komponenten-Bibliotheken. Die Implementierung hängt stark von deinem spezifischen Projekt, deinem Team und den verwendeten Design-Tools ab. Jedes Unternehmen hat unterschiedliche Anforderungen und Workflows — nutze diese Richtlinien als Orientierung, nicht als strikte Regeln. Teste verschiedene Ansätze und finde heraus, was für dein Team am besten funktioniert.