In vielen Interfaces entstehen Buttons „nebenbei“: einmal für die Startseite, einmal fürs Formular, einmal fürs Modal. Nach ein paar Wochen gibt es dann fünf Blautöne, drei Rundungen und Zustände, die mal funktionieren und mal nicht. Genau hier hilft ein klar geplantes Button-System. Es macht Entscheidungen leichter, spart Abstimmungszeit und sorgt dafür, dass Nutzer:innen überall dieselbe Logik vorfinden.
Dieser Artikel erklärt Schritt für Schritt, wie sich Buttons als wiederverwendbare Bausteine aufbauen lassen: welche Varianten wirklich nötig sind, wie Zustände (States) sauber definiert werden und wie das Ganze in Figma/Sketch sowie im Frontend zusammenpasst – ohne Fachchinesisch, aber mit Struktur.
Warum Buttons im System gedacht werden sollten
Konsistenz ist mehr als „gleich aussehen“
Ein Button-System sorgt dafür, dass dieselbe Aktion überall gleich behandelt wird: primäre Handlungen sind klar erkennbar, sekundäre Aktionen drängen sich nicht vor, und gefährliche Aktionen sind eindeutig markiert. Das Ergebnis ist nicht nur hübscher, sondern auch leichter zu bedienen.
Wichtig ist der Unterschied zwischen Optik und Verhalten. Ein Button kann visuell konsistent sein, aber im Verhalten abweichen (z. B. mal ohne Hover, mal mit; mal deaktiviert klickbar, mal nicht). Genau diese Brüche fallen Nutzer:innen schnell auf – besonders in Formularen oder Checkout-Strecken. Für Formulare lohnt sich zusätzlich ein Blick auf Formular-UX mit Validierung und Fehlerzuständen.
Weniger Varianten, mehr Klarheit
Viele Teams starten mit zu vielen Button-Typen: Primary, Secondary, Tertiary, Ghost, Soft, Danger, Info, Success, Link, Icon-only … Das ist selten nötig. Besser ist ein schlanker Kern mit klaren Regeln, wann welcher Typ eingesetzt wird. So bleibt das Design flexibel, ohne beliebig zu werden.
Button-Typen definieren: welche Varianten wirklich nötig sind
Ein pragmatisches Grundset für die meisten Produkte
Für viele Websites und Web-Apps reicht ein Set aus drei visuellen Varianten:
- Primary Button: wichtigste Aktion pro Ansicht (z. B. „Speichern“, „Kaufen“).
- Secondary Button: alternative Aktion, die nicht im Vordergrund stehen soll (z. B. „Zurück“, „Später“).
- Tertiary Button (oder Link-Button): sehr zurückhaltend, oft textbasiert, für weniger wichtige Aktionen (z. B. „Mehr erfahren“).
Zusätzliche Varianten ergeben nur Sinn, wenn sie eine echte Bedeutung tragen. Ein „Ghost“-Button ist zum Beispiel oft nur ein Secondary-Button mit anderem Stil. Wenn er keine andere Rolle hat, ist er eher Styling als System.
Gefährliche Aktionen als eigener Fall
Löschen, Abbrechen von Verträgen oder irreversibles Entfernen von Daten sind Sonderfälle. Hier hilft eine klare Regel: Danger ist keine vierte „Priorität“, sondern eine semantische Kennzeichnung (Bedeutung). Der Button kann also „Primary + Danger“ sein (z. B. roter Primary) oder „Secondary + Danger“ – je nachdem, ob es die Hauptaktion im Dialog ist.
States festlegen: so verhalten sich Buttons in jeder Situation
Die wichtigsten Zustände im Alltag
Buttons sollten mindestens diese Zustände bekommen: Default (normal), Hover (Maus darüber), Active/Pressed (gedrückt), Focus (per Tastatur ausgewählt), Disabled (deaktiviert), Loading (arbeitet). Diese Zustände sind kein Luxus, sondern verhindern echte UX-Probleme: fehlendes Focus-Feedback macht Tastaturbedienung schwer, und fehlende Loading-States führen zu Doppelklicks.
Damit das System stabil bleibt, sollten States pro Variante gleich gedacht werden. Ein Secondary-Button braucht ebenfalls Focus/Disabled/Loading – nur eben im passenden Stil.
Focus sichtbar machen – ohne den Look zu ruinieren
Der Focus-State zeigt, welches Element gerade per Tastatur aktiv ist (z. B. beim Tabben). Ein häufiger Fehler ist, den Focus „wegzudesignen“, weil er angeblich stört. Besser ist eine bewusst gestaltete Fokus-Markierung, die zur UI passt, aber deutlich bleibt. Wer hier tiefer einsteigen will, findet ergänzende Prinzipien in Barrierefreiheit im Web verständlich erklärt.
Disabled vs. Loading: zwei verschiedene Botschaften
Disabled bedeutet: „Diese Aktion ist gerade nicht möglich“ (z. B. Formular unvollständig). Loading bedeutet: „Die Aktion wurde gestartet, bitte warten“. Beide Zustände sollten sich unterscheidbar anfühlen. Praktisch ist außerdem eine Regel im System: Während Loading sollte der Button nicht mehrfach auslösbar sein (Interaktion blockieren), damit keine doppelten Requests entstehen.
Text, Icon, Größe: Regeln, die Alltagstauglichkeit bringen
Button-Labels: kurz, konkret, handlungsorientiert
Gute Button-Texte sagen, was passiert: „Rechnung herunterladen“ ist klarer als „Download“. „Speichern“ ist meist besser als „OK“. Wichtig ist Konsistenz: Wenn in einem Bereich „Speichern“ steht, sollte es nicht an anderer Stelle „Änderungen übernehmen“ heißen, wenn es dieselbe Aktion ist. Passend dazu hilft Microcopy, die Nutzer:innen führt beim Ton und bei eindeutigen Formulierungen.
Icons: nur, wenn sie wirklich helfen
Icons können Buttons schneller scannbar machen, erzeugen aber auch Interpretationsspielraum. Eine einfache Regel: Icons nur einsetzen, wenn sie allgemein verstanden werden (z. B. Lupe für Suche) oder wenn Text + Icon zusammen die Erkennbarkeit steigern (z. B. „Download“ mit Pfeil). Für icon-only Buttons braucht es besondere Sorgfalt: ausreichende Größe, klare Hover/Focus-States und eine verständliche Beschriftung (z. B. per Tooltip oder Accessible Name im Code).
Größenstufen: lieber wenige, aber konsequent
Viele Systeme fahren gut mit drei Größen: S (kompakt, z. B. in Tabellen), M (Standard), L (prominent, z. B. in Hero/Checkout). Entscheidend ist nicht die Anzahl, sondern die Regel: Wo darf S eingesetzt werden? Wo ist mindestens M Pflicht, damit Touch-Bedienung nicht leidet? Dokumentierte Regeln vermeiden Diskussionen pro Screen.
Ein Button-System in Figma oder Sketch sauber aufbauen
Varianten und Eigenschaften statt Kopien
Buttons sollten als Komponente angelegt werden, deren Eigenschaften (Properties) sich über Varianten steuern lassen: Variante (Primary/Secondary/Tertiary), Status (Default/Hover/Pressed/Focus/Disabled/Loading), Größe (S/M/L), Icon (kein/links/rechts), Breite (auto/full). So entstehen nicht 80 einzelne Komponenten, sondern ein steuerbares Set.
In Figma helfen dafür Varianten und Auto Layout, damit Padding und Icon-Abstände stabil bleiben, auch wenn der Text länger wird. Wer das Prinzip vertiefen möchte: Auto Layout für flexible UI-Komponenten zeigt typische Stolperfallen und Lösungen.
Tokens/Variablen nutzen, damit Stiländerungen planbar sind
Ein Button ist ein Mix aus Farben, Typografie, Abständen, Radius und Schatten. Diese Werte sollten nicht „hart“ in jeder Komponente stecken. Sinnvoller sind zentrale Variablen (z. B. für Hintergrundfarbe, Textfarbe, Border, Radius). Dann lässt sich ein Rebranding oder Dark Mode später steuern, ohne jedes Element einzeln anzufassen. Hier zahlt sich ein gut geplantes Designsystem besonders aus.
Übergabe an Entwicklung: wie Design und Code zusammenfinden
Benennung, die im Alltag funktioniert
Ein System scheitert oft an Namen. Gute Namen sind kurz, eindeutig und stabil. Beispiel: „Button / Primary / M / Default“ ist verständlicher als Fantasienamen. Für die Entwicklung ist zusätzlich hilfreich, wenn visuelle Varianten und semantische Rollen getrennt sind: „variant=primary“ und „tone=danger“ sind klarer als „dangerPrimaryFilled“.
Dokumentation: nicht viel, aber präzise
Eine schlanke Doku reicht, wenn sie die wichtigsten Fragen beantwortet:
- Wann Primary, wann Secondary, wann Tertiary?
- Wie viele Primary-Aktionen pro Ansicht sind erlaubt?
- Wie verhalten sich Disabled und Loading?
- Welche Größen sind für welche Bereiche gedacht?
Ergänzend hilft eine kurze Seite mit Do/Don’t-Beispielen (z. B. „Nicht zwei Primary-Buttons nebeneinander“). Damit werden Reviews schneller und Diskussionen sachlicher.
Entscheidungshilfe für den passenden Button im Screen
Einfacher Entscheidungsweg für typische UI-Situationen
- Ist es die wichtigste Aktion im aktuellen Bereich?
- Ja: Primary wählen.
- Nein: weiter.
- Ist es eine Alternative zur Primary-Aktion (z. B. „Abbrechen“, „Zurück“)?
- Ja: Secondary wählen.
- Nein: weiter.
- Ist es eine eher optionale Aktion (z. B. „Details“, „Mehr Infos“, „Später“)?
- Ja: Tertiary/Link-Button wählen.
- Nein: prüfen, ob es überhaupt ein Button sein sollte (z. B. Toggle, Checkbox, Link).
- Ist die Aktion riskant oder irreversibel?
- Ja: als Danger kennzeichnen (Tone), unabhängig von Primary/Secondary.
Kurzer Praxisblock für den Start in bestehenden Projekten
So lässt sich ein chaotisches Button-Set in 60–120 Minuten ordnen
- Alle vorhandenen Buttons aus 5–10 Screens sammeln (Screenshot oder Komponenten-Übersicht).
- In Gruppen sortieren: „Hauptaktion“, „Alternative“, „Optional“.
- Auf 3 Basisvarianten mappen und Sonderfälle markieren (z. B. Danger).
- States ergänzen: Focus, Disabled, Loading – pro Variante.
- Komponente bauen und alte Buttons Schritt für Schritt ersetzen (nicht alles auf einmal).
Typische Stolperfallen und wie sie sich vermeiden lassen
Zu viele „Sonder-Buttons“ für einzelne Seiten
Wenn ein Screen „einen besonderen Button“ braucht, liegt das Problem oft nicht beim Button, sondern bei der Informationshierarchie. Manchmal ist es eher ein Link, manchmal braucht es eine andere Gruppierung. Ein System sollte Ausnahmen zulassen, aber Ausnahmen müssen begründet und dokumentiert sein.
Unklare Priorität: mehrere Primary-Buttons konkurrieren
Zwei gleich starke Buttons nebeneinander stellen Nutzer:innen vor eine Entscheidung, die das Produkt eigentlich abnehmen sollte. Wenn zwei Aktionen gleich wichtig wirken, lohnt sich ein Schritt zurück: Welche ist der „Happy Path“? Welche ist optional? Bei komplexen Seiten hilft es, die Prioritäten im oberen Bereich sauber zu planen, z. B. nach dem Prinzip aus Inhalte oberhalb der Falz priorisieren.
Inkonsistente Abstände und Radius über Varianten hinweg
Wenn Primary und Secondary unterschiedliche Padding-Werte oder Radien haben, sieht das UI schnell „zusammengewürfelt“ aus. Besser: Form und Spacing bleiben gleich, nur Füllung/Border/Farbe ändern sich je Variante. So bleibt die Familie erkennbar, auch bei Themes oder Dark Mode.
| Problem | Typische Ursache | Praktische Lösung |
|---|---|---|
| Zu viele Button-Stile | Varianten werden als Deko genutzt | Auf 3 Basisvarianten reduzieren, Sonderfälle semantisch lösen |
| Keine klare Tastaturführung | Focus-State fehlt oder ist zu subtil | Focus als festen State definieren und sichtbar gestalten |
| Doppelklicks, doppelte Aktionen | Loading fehlt oder blockiert nicht | Loading-State + Interaktionssperre im Button-Verhalten festlegen |
| Buttons „springen“ bei Übersetzungen | Layout nicht flexibel, feste Breiten | Auto-Layout/Responsive Regeln nutzen, Full-Width als Option definieren |
Ein gutes Button-System wirkt im Alltag unspektakulär – und genau das ist das Ziel. Wenn Entscheidungen schneller fallen, States verlässlich sind und jeder Screen „wie aus einem Guss“ wirkt, arbeitet das System im Hintergrund für bessere UX und weniger Reibung im Team.
