Designsystem-Farben strukturieren – konsistente UI-Paletten planen

Viele Interfaces starten mit einer spontanen Farbwahl – und enden in einem bunt zusammengewürfelten System, das niemand mehr wirklich überblickt. Buttons sehen je nach Seite anders aus, Fehlermeldungen wechseln die Töne und mit jedem neuen Feature kommt eine weitere Farbe dazu.

Ein strukturiertes Farbkonzept im Designsystem löst dieses Problem. Es sorgt dafür, dass Farben klar benannt, technisch sauber hinterlegt und für alle im Team verständlich sind – Design, Entwicklung und Content.

Farbrollen im UI-Designsystem klar definieren

Bevor konkrete Töne festgelegt werden, braucht es eine klare Struktur: Welche Aufgaben sollen Farben im Interface überhaupt übernehmen? Statt mit einzelnen Hexwerten zu starten, hilft es, zuerst in Rollen zu denken.

Basisfarben, Semantic Colors und Neutraltöne

In der Praxis hat sich ein dreigeteilter Aufbau bewährt:

• Basispalette: Markenfarben, die die visuelle Identität tragen – meist 1–3 Primärfarben und 1–2 Akzentfarben.
• Semantic Colors: Funktionsfarben für Zustände wie Erfolg, Fehler, Warnung, Info. Sie sollten unabhängig von der Marke klar lesbar und eindeutig sein.
• Neutraltöne: Grau- und Hintergrundabstufungen für Flächen, Rahmen und Typografie. Sie bilden die Bühne, auf der Akzent- und Markenfarben wirken.

Dieses Raster hilft, spätere Wünsche aus Fachabteilungen einzuordnen. Statt „Wir brauchen hier eine andere Farbe“ lautet die Frage dann „Welche Rolle hat dieses Element? Ist es eine Warnung, ein Hinweis oder eine Marke-Betonung?“.

Markenfarbe in eine UI-taugliche Palette übersetzen

Viele Marken kommen mit genau einem Farbwert aus der CI. Für ein Interface reicht das selten. Aus dieser einen Farbe lässt sich eine ganze Skala ableiten, zum Beispiel in 8–10 Helligkeitsstufen von sehr hell bis sehr dunkel.

Diese Skala erfüllt verschiedene Aufgaben:

• dunklere Stufen für Primärbuttons, aktive Zustände und Headlines
• hellere Töne für Hintergründe, Tags oder dezente Hinweise
• mittlere Stufen für Sekundärbuttons, Rahmen oder Hover-Zustände

Wichtig ist, dass die Abstände zwischen den Stufen sichtbar bleiben – besonders in Kombination mit Weiß und den Neutraltönen. Testen lässt sich das gut direkt im UI-Tool anhand von typischen Komponenten wie Buttons, Formfeldern und Karten.

Farbskalen systematisch aufbauen und benennen

Ein gutes Farbsystem ist nicht nur hübsch, sondern vor allem nachvollziehbar benannt. Statt „helles Blau“ und „Button-Blau“ braucht es neutrale, für alle verständliche Bezeichnungen.

Naming-Konventionen für Farb-Token wählen

Im Designsystem wird zwischen „rohen“ Farben (z. B. Blau 500) und semantischen Farben (z. B. Primary / Danger) unterschieden. Diese Trennung macht das System langlebig, weil später nur noch die Zuordnung angepasst werden muss, nicht alle Komponenten.

Ein erprobtes Schema sieht so aus:

• Rohfarben: color-blue-050, color-blue-500, color-neutral-900
• Semantic Tokens: color-primary, color-primary-hover, color-danger

In vielen Teams werden diese Token später direkt in Code übernommen. Saubere Namen sparen dann Diskussionen und Suchaufwand. Wer bereits mit einem UI-Design-System in Figma arbeitet, sollte früh festlegen, wie Farben in Bibliotheken und Komponenten benannt werden.

Kontrast und Barrierefreiheit von Anfang an mitdenken

Ein häufiger Stolperstein im Farbdesign: Töne sehen auf dem Designer-Monitor gut aus, sind aber für viele Nutzer kaum lesbar. Besonders Text auf farbigen Flächen braucht ausreichenden Kontrast, damit Inhalte für alle Menschen gut wahrnehmbar sind.

Hilfreich sind klare Regeln, etwa:

• Fließtext auf Hintergrund mindestens mittleren Grauwert, kein sehr helles Grau
• Buttons mit Text immer im Kontrasttest prüfen, nicht nur optisch beurteilen
• Spezialfälle wie Disabled-Zustände sparsam einsetzen, damit sie nicht zu blass werden

Wer schon beim Aufbau des Farbsystems Kontrasttest-Tools und Dark-Mode-Szenarien mitführt, spart später aufwendige Anpassungen. Ergänzend lohnt ein Blick auf bestehende Empfehlungen zu Farbkontrasten im UI-Design, um konkrete Schwellenwerte und Praxisbeispiele zu nutzen.

Farb-Token von Design nach Code überführen

Farben entfalten ihre Wirkung im Produkt erst, wenn das Designsystem konsistent in der Entwicklung ankommt. Genau hier entstehen oft Brüche: Designer sprechen von „primärem Blau“, Entwickler sehen nur Hexwerte in der CSS-Datei.

Design-Tools und Design Tokens verknüpfen

Moderne Tools wie Figma, Sketch oder moderne Libraries für Webprojekte setzen auf Design Tokens – kleine, benannte Werte, die Design und Code verbinden. Ein Token für die Primärfarbe hat zum Beispiel einen Namen, einen Hexwert und eine Rolle im Interface.

Praktische Schritte für die Einrichtung:

• Alle Farben im Design-Tool als Styles anlegen und klar benennen
• Eine Liste mit Token-Namen und passenden Werten für die Entwicklung exportieren
• Mit dem Entwicklerteam Abstimmung, wie Tokens in CSS/Design-System-Bibliotheken strukturiert werden

Wer bereits ein technisches Designsystem mit Komponentenbibliothek einsetzt, kann Farb-Token dort als zentrale Konstante pflegen. Änderungen an einer Grundfarbe laufen dann automatisch durch alle Komponenten.

Farbvarianten für Zustände und Interaktion planen

Interfaces bestehen selten nur aus statischen Elementen. Buttons brauchen Hover- und Active-Zustände, Formfelder zeigen Fehler oder Erfolg, Links wechseln bei Interaktion den Ton. Für Nutzer ist das ein wichtiges Feedback, für das Farbkonzept eine weitere Dimension.

Bewährt hat sich ein kleines Set an Zustandsfarben pro Rolle:

• Default: der normale Zustand, der zur Marke passt
• Hover: etwas dunkler oder heller, klar wahrnehmbar
• Active/Pressed: deutlich unterscheidbar, aber nicht fremd wirkend
• Focus: meist mit zusätzlichem Rahmen oder Leuchteffekt statt nur Farbwechsel

Diese Varianten sollten konsequent in allen Komponenten auftauchen, nicht nur in Buttons. Ein Formular, das Fehler rot unterlegt, aber in Tooltipps eine andere Rotvariante nutzt, wirkt schnell unruhig. Konsistenz erleichtert Nutzenden das Verständnis.

Farbsysteme für Light- und Dark-Mode denken

Viele Produkte bieten heute sowohl helle als auch dunkle Oberflächen. Einfach die Farben invertieren reicht dabei nicht aus. Stattdessen braucht es eine logische Übersetzung: Welche Rolle hat ein Ton im Light-Mode, und welcher Ton übernimmt diese Rolle im Dark-Mode?

Hintergründe, Flächen und Highlights abstimmen

Im Dark-Mode werden Flächen oft dunkler, Text und aktive Elemente heller. Das führt schnell zu extremen Kontrasten, die anstrengend wirken können. Ein ausbalanciertes System achtet deshalb auf drei Ebenen:

• Basis-Hintergründe: Grundflächen, auf denen der Hauptinhalt sitzt
• Cards und Module: leicht abgesetzte Flächen für Gruppen von Inhalten
• Highlights: markante Flächen für aktive Zustände, Call-to-Actions, Badges

Für jede dieser Ebenen lassen sich passende Gegenstücke im Light- und Dark-Mode definieren. So bleibt die Hierarchie stabil, auch wenn die Helligkeit wechselt. Gleichzeitig kann die Markenfarbe in dunklen Umgebungen etwas angepasst werden, um Leuchten und Überstrahlen zu vermeiden.

Typografie-Farben im Designsystem konsistent halten

Textfarben werden in Projekten häufig unterschätzt. Schnell entstehen acht verschiedene Grauwerte, weil jeweils „nur ein bisschen heller“ ausprobiert wird. Besser ist ein minimales, bewusst gewähltes Set:

• Primary Text: Standardfarbe für Fließtext und Headlines
• Secondary Text: abgeschwächt für Labels, Meta-Informationen
• Disabled Text: klar erkennbar, aber noch lesbar
• Inverted Text: für Text auf farbigen Flächen oder Buttons

Alle diese Töne sollten den Kontrastanforderungen im geplanten Kontext entsprechen. Ein Designsystem profitiert davon, wenn Typografie-Farben genauso bewusst geplant sind wie Buttons und Flächen. In vielen Teams werden sie gleichzeitig mit der Typografie im UI-Designsystem definiert.

Farbkonzept dokumentieren und im Alltag nutzbar machen

Selbst das beste Farbsystem bringt wenig, wenn es nur im Kopf der Designer existiert. Verständliche Dokumentation stellt sicher, dass alle Beteiligten die Logik kennen und anwenden können – auch neue Teammitglieder oder externe Partner.

Styleguide und UI-Kit mit Beispielen anlegen

Digitale Produkte profitieren von einer leicht verständlichen Farbdokumentation, die nicht nur Werte, sondern vor allem Einsatzzwecke zeigt. Ein praktischer Aufbau:

• Tabelle der Rohfarben mit Namen, Hexwerten und Einsatzbereichen
• Übersicht der Semantic Colors mit Beispielen (z. B. Fehlermeldung, Erfolg, Info)
• Beispielkomponenten: Buttons, Formfelder, Badges, Karten – jeweils mit Zuständen

Wer seine Farbpalette in einem lebenden UI-Kit pflegt, kann Änderungen an einer Stelle durchführen und automatisch in alle Screens übernehmen. Das reduziert Pflegeaufwand und hält das Farbsystem aktuell.

Typische Fehler beim Farb-Designsystem vermeiden

Einige Probleme wiederholen sich in vielen Teams und lassen sich mit klaren Regeln leicht umgehen:

• Zu viele Farben: Jedes neue Feature bringt eine extra Farbe mit – besser ist eine Erweiterung innerhalb bestehender Skalen.
• Uneinheitliche Zustände: Erfolgsmeldungen wechseln von grün zu blau, je nach Modul – hier helfen feste Semantic Colors.
• Fehlende Tests: Farben werden nur im leeren Layout bewertet, nicht im echten Inhalt mit Bildern, Texten und komplexen Modulen.

Ein regelmäßiger Review des Farbsystems, etwa einmal pro Quartal, hält die Palette in Form und verhindert schleichendes Chaos.

So geht’s: In 7 Schritten zum strukturierten Farbsystem

Als kompakter Einstieg hier eine konkrete Schritt-für-Schritt-Checkliste, mit der sich ein neues oder bestehendes Farbsystem im Produkt überarbeiten lässt.

• Bestehende Farben inventarisieren: Alle aktuell genutzten Hexwerte sammeln und gruppieren.
• Farbrollen definieren: Basispalette, Semantic Colors und Neutraltöne festlegen.
• Skalen aufbauen: Pro Hauptfarbe Helligkeitsstufen anlegen und einsatztauglich testen.
• Naming-System festlegen: Klare Token-Namen für Rohfarben und semantische Farben definieren.
• Kontraste prüfen: Typische Kombis (Text auf Flächen, Buttons, Hinweise) mit Tools testen.
• Tokens in Design und Code bringen: Styles im UI-Tool anlegen, in Entwicklung spiegeln.
• Dokumentation pflegen: Styleguide mit Beispielen erstellen und regelmäßig aktualisieren.

Kleine Vergleichsbox: Ad-hoc-Farbwahl vs. strukturiertes Farbsystem

Wer die eigene Produktpalette mit ein paar gezielten Entscheidungen strukturiert, legt eine verlässliche Basis für alle kommenden Features – und erspart sich viele Diskussionen über einzelne Töne. Ein durchdachtes UI-Farbsystem ist damit kein Luxus, sondern ein zentrales Werkzeug für klare, wartbare Interfaces.