Eine Component Library in Figma ist eine zentral gepflegte Sammlung von Komponenten, Styles und Variables, die als geteilte Library für ein Team oder eine Organisation veröffentlicht wird und konsistentes Design auf Knopfdruck ermöglicht.
Rubrik: Software & Tools Deep-Dive · Unterrubrik: Figma · Niveau: Profi Synonyme / Auch bekannt als: Design System Library, Figma Team Library, Shared Library, Published Library
Was ist eine Component Library?
Eine Component Library ist das digitale Fundament eines Design-Systems. Sie enthält alle wiederverwendbaren Design-Bausteine eines Projekts oder einer Organisation – von einfachen Buttons bis hin zu komplexen Organisms wie Navigationsleisten oder Datentabellen.
In Figma wird eine Component Library als spezielle Datei erstellt, die dann über die "Publish"-Funktion für alle Mitglieder eines Teams zugänglich gemacht wird. Jede Figma-Datei des Teams kann die Library importieren und die Komponenten, Styles und Variables nutzen – und erhält automatisch Updates, wenn die Library aktualisiert wird.
Erklärung
Grundlegende Konzepte
Library-Datei vs. Projekt-Datei: Die Library-Datei enthält alle Master-Komponenten, Styles und Variables. Projekt-Dateien nutzen Instances (Kopien) dieser Komponenten. Änderungen an einem Master propagieren sich zu allen Instances.
Veröffentlichen (Publish): Über das Assets-Panel > Libraries > "Publish" wird die Library für das Team freigegeben. Jede Aktualisierung muss explizit mit einer Beschreibung der Änderungen gepublished werden – ähnlich einem Git-Commit.
Update-Workflow: Wenn eine Library aktualisiert wird, erscheint in allen Dateien, die sie nutzen, eine Update-Benachrichtigung. Designer können Updates reviewen und selektiv akzeptieren.
Aufbau einer Component Library
#### Schritt 1: Foundations definieren
Bevor Komponenten gebaut werden, müssen die Design-Grundlagen als Styles und Variables festgelegt werden:
- Farbpalette: Primär-, Sekundär-, Neutral- und semantische Farben (Success, Error, Warning) als Figma: Styles – Zentral verwaltete Design-Tokens für Farben und Typografie oder Figma: Variables – Token-basiertes Design mit Modi und Aliassen
- Typografie: Schriftarten, Größen, Gewichtungen, Zeilenhöhen als Text-Styles
- Spacing: 8-Punkt-Grid-basierte Abstände als Variables oder Dokumentation
- Elevation / Shadows: Box-Shadow-Styles für Cards, Modals etc.
- Border Radius: Einheitliche Abrundungen als Variables
#### Schritt 2: Atoms bauen (Atomic Design)
Analog zum Atomic Design-Prinzip (Brad Frost, 2016) beginnt man mit den kleinsten, unteilbaren Elementen:
- Farb-Swatches
- Icons (über ein Icon-System oder Iconify-Plugin)
- Typografie-Specimens
- Spacing-Tokens-Dokumentation
#### Schritt 3: Komponenten mit Variants erstellen
Für jeden UI-Baustein werden alle nötigen Zustände als Figma: Variants – Alle Zustände einer Komponente in einem Set definiert:
Button-Beispiel:
- Variant Properties: Type (Primary, Secondary, Ghost, Danger), Size (Small, Medium, Large), State (Default, Hover, Pressed, Disabled), Icon (With Icon, Without Icon)
- Ergibt: 4 × 3 × 4 × 2 = 96 Varianten
Input Field-Beispiel:
- Variant Properties: State (Empty, Focused, Filled, Error, Disabled), Size (Small, Medium)
- Mit Interactive Components in Figma für Hover/Focus-Animationen
#### Schritt 4: Molecules und Organisms zusammensetzen
Größere Komponenten aus Atoms zusammenbauen:
- Form (aus Input Fields, Labels, Buttons)
- Card (aus Image, Heading, Body, CTA)
- Navigation (aus Logo, Nav-Items, CTA-Button)
#### Schritt 5: Dokumentation
Eine gute Library enthält Dokumentation direkt in der Figma-Datei:
- Nutzungsrichtlinien für jede Komponente
- Do's and Don'ts-Beispiele
- Code-Referenzen (Komponentenname, Props)
- Accessibility-Hinweise
Figma Component Properties
Seit 2022 bietet Figma Component Properties, die es erlauben, Komponenten-Instances direkt im Design-Panel zu konfigurieren – ohne in die Komponente einzutauchen:
- Boolean Properties: Zeige/verstecke Layer (z.B. Icon sichtbar: ja/nein)
- Text Properties: Direkte Textbearbeitung im Properties-Panel
- Instance Swap Properties: Tausche verschachtelte Komponenten aus (z.B. verschiedene Icons)
- Variant Properties: Wechsle zwischen Varianten
Library-Management und Governance
Für größere Teams ist ein klares Governance-Modell wichtig:
Wer darf publizieren? In der Regel nur ein dediziertes Design-System-Team oder Lead-Designer. Figma ermöglicht Editor-Berechtigungen auf Library-Ebene.
Wie werden Breaking Changes kommuniziert? Publish-Beschreibungen nutzen, Changelog führen (z.B. als Page in der Library-Datei), Team über Updates informieren.
Wie wird die Library deprecated? Alte Komponenten nicht sofort löschen, sondern zunächst als "Deprecated" markieren. Zeitraum für Migration definieren.
Multiple Libraries
Figma erlaubt mehrere Library-Dateien pro Team. Ein sinnvolles Setup:
- Foundation Library: Farben, Typografie, Icons, Spacing
- Core Component Library: Buttons, Forms, Cards, Navigation
- Pattern Library: komplexe, anwendungsspezifische Muster
- Brand Library: Logo-Versionen, Illustrationen, Fotostile
Beispiele
Beispiel 1: Medienunternehmen Design System Ein Verlag mit drei Digitalmarken (Nachrichtenportal, Magazin, Podcast-App) baut eine gemeinsame Foundation Library (gemeinsame Spacing, Typografie) und drei markenspezifische Farb- und Komponenten-Libraries. Teams können die Foundation nutzen und überschreiben.
Beispiel 2: SaaS-Produktteam Ein 15-köpfiges Designteam pflegt eine zentrale Component Library mit 200+ Komponenten. Jede neue Feature-Entwicklung nutzt automatisch aktuelle Komponenten. Ein Design-System-Lead reviewed monatlich neue Patterns und entscheidet, welche in die Library aufgenommen werden.
Beispiel 3: Agentur mit Multiple-Client-Setup Eine Digitalagentur hat eine interne Basis-Library für oft verwendete Patterns und erstellt pro Kundenprojekt eine spezifische Library, die die Basiskomponenten überschreibt oder erweitert.
In der Praxis
Häufige Fehler beim Library-Aufbau:
- Zu früh zu viel: Libraries zu früh und zu komplex aufbauen, bevor echte Design-Bedürfnisse bekannt sind. Besser: Iterativ aufbauen, was gebraucht wird.
- Schlechte Namenskonventionen: Inkonsistente Benennung macht Libraries unnutzbar. Empfehlung:
[Category]/[Component]/[Variant]z.B. "Forms/Input/Focused-Medium" - Keine Dokumentation: Komponenten ohne Nutzungskontext sind schwer verwendbar. Jede Komponente braucht mindestens einen Satz Kontext.
- Zu viele Varianten: Nicht jede theoretisch mögliche Kombination braucht eine eigene Variante. Nur Zustände, die tatsächlich gebraucht werden.
- Library und Projektdatei vermischt: Komponenten direkt in Projektdateien zu bauen, statt in der Library, führt zu Inkonsistenzen.
Vergleich & Abgrenzung
Figma Library vs. Sketch Symbols: Sketch Symbols sind das Äquivalent zu Figma-Komponenten – aber ohne nativen Shared-Library-Mechanismus. Drittanbieter-Tools wie Abstract oder Craft wurden dafür genutzt.
Figma Library vs. Storybook: Storybook ist die Code-Seite des Design-Systems (Komponenten in React, Vue, Angular). Eine Figma Library ist die Design-Seite. Idealer Workflow: Design und Code-Komponenten sind synchron gehalten.
Figma Library vs. Tokens Studio: Tokens Studio synchronisiert Design Tokens (Variablen) zwischen Figma und Code-Repositories. Es ergänzt die Library, ersetzt sie aber nicht.
Häufige Fragen (FAQ)
Wie viele Komponenten braucht eine gute Library? Es gibt keine magische Zahl. Ein solides System startet mit 20–50 Kernkomponenten (Buttons, Inputs, Cards, Navigation, Typography) und wächst iterativ.
Kann ich eine externe Library (z.B. Material Design) in mein Projekt einbinden? Ja – öffentliche Figma-Community-Files (z.B. Material Design 3, Apple HIG) können als Library dupliziert und in das eigene Team eingebunden werden.
Wie synchronisiere ich die Figma Library mit dem CSS/JS-Code? Über Tokens Studio und Style Dictionary kann eine Synchronisation zwischen Figma Variables/Tokens und CSS Custom Properties oder Design-Token-Formaten hergestellt werden. Details im Eintrag Figma: Design Tokens – Die gemeinsame Sprache von Design und Code.
Was passiert, wenn ich eine Komponente aus der Library lösche? Instances in Projektdateien werden "detached" – sie verlieren ihre Library-Verbindung und bleiben als lokale Kopien bestehen, erhalten aber keine Updates mehr.
Verwandte Einträge
- Figma: Components – Wiederverwendbare UI-Bausteine im Design System – Einzelne Komponenten bauen
- Figma: Variants – Alle Zustände einer Komponente in einem Set – Varianten für Komponenten
- Figma: Styles – Zentral verwaltete Design-Tokens für Farben und Typografie – Styles in Libraries
- Figma: Variables – Token-basiertes Design mit Modi und Aliassen – Variables und Tokens
- Figma: Design Tokens – Die gemeinsame Sprache von Design und Code – Token-System
- Figma: Branching – Versionsmanagement wie in der Softwareentwicklung – Versionierung der Library
Weiterführend
- Frost, B. (2016): Atomic Design. Brad Frost.
- Figma Help Center (2024): Share Styles, Components, and Variables with Team Libraries.
- Saarinen, J. (2021): Design Systems Handbook. DesignBetter.co.
- Vesselov, M. / Davis, T. (2019): Building Design Systems. Apress.
- Nathan Curtis (2023): Component Anatomy. EightShapes.
