Ein starkes Designsystem lebt von wiederverwendbaren Bausteinen. In Figma übernehmen Komponenten genau diese Rolle: Buttons, Formularfelder, Karten, Header – einmal sauber gebaut, beliebig oft genutzt. So entsteht eine UI, die konsistent bleibt, auch wenn mehrere Personen parallel daran arbeiten.
Der folgende Leitfaden zeigt, wie ein Set aus gut strukturierten Komponenten in Figma aufgebaut wird, welche Namenskonventionen helfen, wie Varianten und Interaktionen organisiert werden und wie das Ganze später in der Zusammenarbeit mit Entwicklung und Redaktion funktioniert.
Grundlagen von Figma Komponenten im Designsystem
Bevor es ins Detail geht, lohnt sich ein kurzer Blick auf die Grundlagen: Was ist eine Komponente, wie unterscheidet sie sich von Instanzen und warum spielt das für ein Designsystem eine so große Rolle?
Was eine Komponente in Figma eigentlich ist
In Figma ist eine Komponente ein Master-Baustein. Jede Kopie davon ist eine „Instance“ (Instanz). Änderungen an der Master-Komponente können später auf alle Instanzen übertragen werden – etwa wenn sich Farben, Eckenradius oder Typografie ändern.
Typische Beispiele:
- Primary-Button, Secondary-Button, Text-Button
- Formularfelder mit Label, Fehlerzustand und Hilfe-Text
- Navigationselemente, Karten-Layouts, Produkt-Teaser
So wird aus einzelnen Screens ein System aus klar definierten Bausteinen – ähnlich wie ein Lego-Kasten. Wer bereits mit Farb-Token in Figma arbeitet, ergänzt mit Komponenten den logischen nächsten Schritt.
Instanzen vs. Duplikate – warum das wichtig ist
Ein häufiges Missverständnis: Objekte einfach nur zu duplizieren, schafft noch kein Designsystem. Nur Instanzen behalten den Bezug zur Master-Komponente. Wer also mit Copy & Paste arbeitet, verliert diese Verbindung und damit die Möglichkeit, das UI später zentral anzupassen.
Saubere Regel: Für UI-Elemente, die in mehreren Screens vorkommen, immer eine Komponente anlegen und Instanzen verwenden. Freie Duplikate nur dort, wo ein Element wirklich einzigartig bleibt.
Struktur und Benennung für Figma Komponenten
Ein Designsystem steht und fällt mit einer klaren Struktur. Ohne sinnvolle Benennung und Ordnerlogik wird selbst das schönste Set an Komponenten schnell unübersichtlich.
Namenskonventionen für UI-Komponenten
Eine gut lesbare Namenskonvention hilft, Elemente in der Figma-Asset-Liste schnell zu finden. Bewährt haben sich hier steuernde Präfixe und Hierarchien mit „/“ als Trenner.
Beispiel für Buttons:
- Button/Primary/Default
- Button/Primary/Hover
- Button/Primary/Disabled
Und für Formular-Elemente:
- Input/Text/Default
- Input/Text/Error
- Input/Text/Success
So kann Figma die Struktur direkt in den Assets abbilden. Designerinnen und Designer finden schneller, was gebraucht wird, und das System bleibt auch in größeren Teams beherrschbar.
Komponenten in einer Library organisieren
Für mittlere und größere Projekte empfiehlt sich eine zentrale Library-Datei, in der alle Grundlagen-Bausteine liegen:
- Farben und Typografie-Stile
- Grund-Komponenten wie Buttons, Inputs, Badges, Tags
- Layout-Module wie Karten, Listen-Elemente, Navigation
Diese Datei wird als Library veröffentlicht und in anderen Projekt-Dateien eingebunden. So bleibt das UI-System an einer Stelle wartbar, während Produkt-Teams eigene Seiten, Flows und Prototypen auf Basis dieser Komponenten bauen.
Button-Komponenten mit Varianten in Figma anlegen
Buttons sind oft der Einstieg in ein Designsystem. Hier lässt sich gut zeigen, wie Varianten, States und Interaktionen aufgebaut werden.
Schritt-für-Schritt: aus einem Button ein System machen
Ein pragmatischer Aufbau für Button-Komponenten:
- Basis-Form (z. B. abgerundetes Rechteck) mit Auto Layout für Text-Innenabstand
- Textstil über definierten Typografie-Style
- Farbflächen über definierte Farb-Styles (z. B. „Primary/500“)
- Komponente erstellen und sinnvoll benennen, etwa „Button/Primary“
Anschließend werden mit „Create Component Set“ Varianten erstellt, zum Beispiel:
- State=Default, State=Hover, State=Pressed, State=Disabled
- Size=Small, Size=Medium, Size=Large
In der rechten Seitenleiste können Variablen wie „State“ und „Size“ gepflegt werden. In den Instanzen stehen diese Eigenschaften später als Dropdown zur Verfügung – das beschleunigt den Alltag enorm und hält das visuelle Verhalten konsistent.
Interaktionen und Prototyping direkt im Button hinterlegen
Wer Prototypen baut, sollte Interaktionen möglichst in der Komponente selbst definieren. Ein Hover-State oder eine Klick-Animation wird dann direkt mit dem zuständigen Variant-State verknüpft. So sind alle Instanzen automatisch interaktiv.
Vorteil: Statt jeden Screen einzeln zu verkabeln, reicht die Logik der Komponente. Das spart Zeit gerade bei komplexeren Flows und passt gut zu strukturierten Workflows, wie sie etwa beim Landingpage-Design in Figma üblich sind.
Komplexere UI-Komponenten: Formularfelder, Cards, Navigation
Sobald Buttons stehen, lohnt der Schritt zu komplexeren Komponenten. Gerade Formularfelder und Karten profitieren stark von Varianten und klarer Struktur.
Formular-Komponenten mit Zuständen und Fehlermeldungen
Formular-Elemente bestehen oft aus mehreren Teilen: Label, Eingabefeld, Hilfe-Text, Fehlermeldung, Icon. Hier hilft Auto Layout, um flexible, skalierbare Komponenten zu bauen.
Sinnvolle Varianten:
- State: Default, Focus, Error, Success
- Label: Visible, Hidden (für Spezialfälle)
- Icon: None, Left, Right
Über Boolean-Properties (Schalter) können z. B. Hilfe-Text oder Fehlermeldung ein- und ausgeblendet werden. So bleibt eine einzige Komponente vielseitig genug für alle gängigen Fälle und muss nicht in zehn verschiedene Versionen aufgespalten werden.
Card-Layouts als modulare Bausteine
Karten (Cards) sind typische UI-Bausteine für Produkt-Teaser, Blog-Übersichten oder Feature-Listen. Ein sauberes Card-System hat meist folgende Bestandteile:
- Bildbereich oder Icon-Fläche
- Titel und Beschreibungstext
- Call-to-Action (Link oder Button)
Auch hier empfiehlt sich Auto Layout, um unterschiedliche Textlängen oder Bildformate sauber aufzufangen. Varianten können z. B. zwischen Bild- und Icon-Variante, Light/Dark-Hintergrund oder verschiedenen Größen unterscheiden.
Navigation und Header-Komponenten strukturieren
Navigationen und Header sind für die Nutzbarkeit einer Website entscheidend und sollten deshalb besonders stabil aufgebaut sein. Eine typische Struktur:
- Header-Bar (Logo, Hauptnavigation, CTAs)
- Mobile-Variante mit Burger-Menü und Overlays
- States: Default, Scrolled, Sticky
Durch Overrides in Instanzen lassen sich Menüpunkte flexibel austauschen, während Abstände, Schriftgrößen und Interaktionen konsistent bleiben. Das zahlt direkt auf eine ruhige User Experience ein – im Sinne von durchdachtem White Space im UX-Design.
Komponenten, Tokens und Responsive Layout zusammendenken
Ein Designsystem entfaltet seine Wirkung erst richtig, wenn Komponenten, Design-Tokens und Layout-System zusammenarbeiten.
Farben und Typografie als Basis für Komponenten
Alle Farbflächen und Texte innerhalb der Komponenten sollten an Styles gebunden sein. So können globale Änderungen – etwa bei einer CI-Aktualisierung – zentral erfolgen. Gerade für Farben lohnt ein System mit unterschiedlichen Stufen (z. B. 50–900), das in Figma bereits als Styles angelegt ist.
Ähnlich wichtig: ein klarer Satz an Typografie-Stilen, etwa für Überschriften, Fließtexte, Labels und Captions. Diese werden in Komponenten konsequent genutzt, sodass später keine „freien“ Schriftgrößen oder Abstände entstehen.
Responsive Verhalten der Komponenten planen
Figma bietet flexible Layout-Einstellungen, die sich hervorragend für responsives Verhalten eignen. In Verbindung mit einem Responsive Webdesign zahlt sich das direkt aus.
Wichtige Einstellungen:
- Auto Layout für Buttons, Cards, Navigation
- Constraints (Ausrichtungen) für Elemente in Containern
- Min/Max-Breiten für wichtige Bausteine
Eine Karte etwa kann auf Desktop zweispaltig mit Bild und Text erscheinen, auf kleineren Breakpoints aber automatisch vertikal anordnen. So lässt sich das Verhalten schon im Design nachvollziehen, bevor Entwicklerinnen und Entwickler es im Code abbilden.
Checkliste: stabile Figma Komponenten für den Alltag
Die folgende Checkliste hilft, neu gebaute Komponenten auf Alltagstauglichkeit zu prüfen.
- Jede Komponente hat einen klaren Namen mit Hierarchie (z. B. „Button/Primary/Default“).
- Alle Farben und Schriften nutzen definierte Styles.
- Varianten sind sinnvoll benannt (State, Size, Type) und nicht überladen.
- Auto Layout ist überall dort aktiv, wo Inhalte in der Größe variieren können.
- Interaktionen (z. B. Hover) sind in der Komponente selbst definiert.
- Instanzen werden genutzt, keine losen Duplikate der Komponenten.
- Komponenten liegen in einer gemeinsamen Library-Datei und sind veröffentlicht.
Zusammenarbeit: Komponenten im Team und mit Entwicklung nutzen
Sobald das Komponentenset steht, wird es zum Dreh- und Angelpunkt im Alltag. Gerade im Zusammenspiel mit Entwicklung und Content-Teams zeigt sich, wie robust das System wirklich ist.
Design-Handoff mit klaren Komponenten erleichtern
Entwicklerinnen und Entwickler profitieren von sauber aufgebauten Komponenten, weil diese oft direkt mit ihren UI-Komponenten im Code korrespondieren. Wer im Design schon in wiederverwendbaren, klar benannten Bausteinen denkt, erleichtert das Mapping zu React-, Vue- oder Web-Components deutlich.
Hilfreich ist hier ein abgestimmter Handoff-Prozess, wie er z. B. bei einem strukturierten Design-Handoff aus Figma empfohlen wird: klare Beschreibungen, definierte States, dokumentierte Interaktionen.
Komponentendokumentation im Figma-File
Kurze Hinweise direkt im Figma-File helfen dem gesamten Team, Komponenten korrekt zu nutzen. Dazu bieten sich z. B. an:
- eine Einführungsseite mit Legende und Anwendungsbeispielen
- Beschreibungstexte in der Seitenleiste (Description-Feld)
- kleine Beispiele für richtige und falsche Nutzung
So wird das Designsystem nicht nur ein Baukasten für Profis, sondern ein Werkzeug, das auch neue Teammitglieder schnell verstehen.
Mini-Ratgeber: häufige Fehler bei Figma Komponenten vermeiden
Einige Stolperfallen tauchen in fast jedem Projekt auf. Ein kurzer Blick darauf spart später viel Zeit.
- Komponenten ohne System: Wenn jeder Button anders heißt, hilft auch die beste Library wenig. Eine einfache Naming-Regel wirkt hier Wunder.
- Zu viele Varianten: Wenn jede Kleinigkeit eine eigene Variante bekommt, wird die Komponente unübersichtlich. Lieber mit Properties (z. B. Booleans) arbeiten und auf die wirklich relevanten States fokussieren.
- Unklare Verantwortlichkeit: Ohne klare Zuständigkeit verwaist ein Designsystem. Es braucht mindestens eine Person oder ein kleines Team, das Änderungen koordiniert.
- Fehlende Abstimmung mit Code: Wenn das Designsystem völlig anders strukturiert ist als die Codebasis, entstehen Brüche. Ein gemeinsames Vokabular und regelmäßiger Austausch helfen, das zu vermeiden.
Gut gepflegte Komponenten bilden die Grundlage für konsistente Interfaces, schnellere Workflows und weniger Diskussionen über Details. Zusammen mit sauberen Texten, einem klaren Grid und einem bewussten Umgang mit UI/UX-Design entsteht so ein System, das langfristig trägt.
