Warum Farbwahl im Product Design 2026 keine Bauchentscheidung mehr ist — und wie du semantische Farbrollen, Kontrast und Themes so aufbaust, dass Marke, UX und Barrierefreiheit gleichzeitig funktionieren
Farbe ist das erste, was Nutzer:innen von deinem Produkt wahrnehmen — noch bevor sie die erste Headline lesen oder den ersten Button verstehen. Sie transportiert Stimmung, weist auf Interaktion hin, gruppiert Inhalte, warnt vor Fehlern und trägt einen Großteil der Markenwirkung. Trotzdem entstehen Farbpaletten in vielen Web- und App-Projekten so: Die Markenfarbe aus dem Styleguide wird übernommen, ein paar Grautöne dazugelegt, Rot für Fehler, Grün für Erfolg — und der Rest entsteht im Sprint.
Farbsysteme im Webdesign sind 2026 eine eigene Disziplin. Wer sie ernst nimmt, gewinnt Klarheit, Konsistenz und Barrierefreiheit — ohne dass die Marke leidet. Wer sie ignoriert, sammelt über Monate 47 Grautöne im Code, drei verschiedene Rot-Werte für Fehler und eine Primärfarbe, die im Dark Mode wie ein Warnsignal blinkt.
Dieser Artikel zeigt, wie du Farbe in digitalen Produkten systematisch angehst: von der Herleitung einer Palette über semantische Rollen und Design Tokens bis zu Themes, States und Barrierefreiheit — mit Mustern, die sowohl im kleinen Startup als auch im großen Design-System tragen.
Farbe ist die schnellste Sprache deines Interfaces. Ein Grauton kann Ruhe oder Verwirrung erzeugen, ein Grün kann Vertrauen oder Warnung bedeuten. Ein gutes Farbsystem legt fest, welche Bedeutung du in deinem Produkt trägst — bevor der erste Screen entsteht.
Bevor wir ins Handwerk gehen, ein ehrlicher Blick auf typische Ursachen. In Produkt-Audits begegnet mir dieselbe Diagnose immer wieder: Die visuelle Sprache stimmt in einzelnen Screens, aber die Palette dahinter ist ein historisch gewachsener Flickenteppich.
Was auf dem Logo funktioniert, funktioniert selten als Interface-Farbe. Ein sattes Rebranding-Blau wirkt auf 200 Pixel Fläche stark — auf einer ganzen Dashboard-Seite kann es hart und ermüdend werden. Marken-Primary und UI-Primary sind verwandt, aber nicht identisch.
Jeder neue Screen bringt einen neuen Grauton mit: #f5f5f5 für die Card, #ececec für den Divider, #dcdcdc für den disabled State, #a0a0a0 für die Caption. Nach einem halben Jahr hat die Codebase zwölf Grauwerte, von denen sich viele um weniger als drei Prozent unterscheiden — für das Auge nicht unterscheidbar, für die Wartung ein Alptraum.
„Rot heißt Fehler" — welches Rot genau? Und in welchem Ton auf dunklem Hintergrund? Ohne semantische Rollen (color-error, color-success, color-warning) entstehen Farbentscheidungen jedes Mal neu, und jede:r Designer:in trifft sie leicht anders.
Der Klassiker: Die Palette entsteht für den Light Mode. Sechs Monate später kommt Dark Mode dazu — und plötzlich passen weder die Markenfarbe noch die Zustandsfarben. Wer Dark Mode nicht von Anfang mitplant, baut ihn dreimal um. Details dazu im Artikel zu Dark Mode richtig umsetzen.
Diagnose-Tipp: Öffne den kompilierten CSS-Output deines Produkts und zähle, wie viele unterschiedliche Hex-Werte darin auftauchen. Bei den meisten Web-Apps findest du zwischen 40 und 120. Ein sauberes System braucht etwa 25 bis 40.
Kaum ein Thema wird im Webdesign so überstrapaziert wie Farbpsychologie. „Blau schafft Vertrauen, Grün steht für Wachstum, Rot signalisiert Gefahr" — solche Sätze klingen plausibel, sind aber nur die halbe Wahrheit.
Farbpsychologie ist ein grober Kompass, kein Rezeptbuch. Nutze sie, um plausible Startpunkte zu setzen — und teste die tatsächliche Wirkung im Kontext deines Produkts. Der Farbton allein entscheidet selten. Sättigung, Kontrast, Umgebung und semantische Konsistenz entscheiden fast immer.
Der Weg von einer Markenfarbe zu einem funktionierenden UI-System läuft in vier Schritten — und die meisten Teams überspringen die mittleren beiden.
Die Markenfarbe (oder zwei bis drei davon) ist gesetzt. Sie stammt aus dem Corporate Design und wird in Logo, Marketing und Kampagnen konsistent verwendet.
Die Marken-Primary ist selten die beste UI-Primary. Häufig muss sie leicht abgewandelt werden, um in Fließtext, Buttons und Interaktionsflächen zu funktionieren — meist einen Tick entsättigt oder abgedunkelt, damit sie auf großen Flächen nicht sticht. Das Ergebnis ist eine UI-Primary, die zur Marke passt, aber im Interface arbeitet.
Aus jedem tragenden Farbton wird eine Rampe generiert — typischerweise neun bis elf Abstufungen zwischen fast weiß und fast schwarz. Das gibt dir für jede Farbe ein ganzes Spektrum:
Tools wie Radix Colors, Tailwind's Farbrampen, Leonardo (Adobe) oder Huetone helfen beim Generieren — sie berücksichtigen perzeptive Helligkeit statt nur mathematischer Mischung.
Grau ist nicht gleich Grau. Ein rein neutrales Grau (HSL-Sättigung 0) wirkt technisch und kalt. Ein leicht warmes Grau (mit einer Spur Rot oder Gelb) wirkt organischer. Ein leicht kühles Grau (mit einer Spur Blau) wirkt professionell und modern. Deine neutrale Rampe ist eine gestalterische Entscheidung — nicht der Default.
Der wichtigste Schritt beim Aufbau eines Farbsystems ist die Trennung zwischen primitiven Farben (rohe Hex-Werte) und semantischen Rollen (wofür eine Farbe steht).
Eine primitive Farbe ist blue-600 = #1d5eff. Eine semantische Rolle ist color-action-primary. Im Produkt referenzierst du niemals blue-600 direkt, sondern nur color-action-primary. Der Vorteil: Wenn die Marke morgen von Blau auf Violett wechselt, änderst du einen Tokenwert — nicht 400 CSS-Zeilen.
Ein tragfähiges Set semantischer Rollen enthält meist:
Semantische Rollen sind der Punkt, an dem Design-System und Codebase konvergieren. Ohne sie ist jedes Refactor ein Handarbeitsprojekt. Mehr zum Aufbau von Design-Systemen in kleinen Teams im Artikel zu Design Systems für kleine Teams.
In größeren Systemen hat sich eine dreistufige Struktur bewährt:
blue-600, gray-100)color-action-primary, color-surface-elevated)button-primary-background)Kleine Teams brauchen die dritte Ebene selten. Die ersten beiden sind fast immer die Mühe wert.
Merksatz: Wer im Code
#1d5effschreibt, hat sein Farbsystem verloren. Wercolor-action-primaryschreibt, hat es gefunden.
Farbwirkung entsteht nie aus einem einzelnen Farbton, sondern aus dem Zusammenspiel dreier Achsen — Farbton (Hue), Sättigung (Saturation), Helligkeit (Lightness). Wer alle drei bewusst steuert, kommt mit weniger Farben zu klareren Interfaces.
Ein häufiger Fehler: Fünf verschiedene Farben auf einem Screen, alle voll gesättigt. Das Auge weiß nicht mehr, wohin. Reduziere Sättigung für alle nicht-tragenden Elemente — Icons, Meta-Informationen, Hintergrundbadges — und behalte volle Sättigung nur für das, was wirklich Aufmerksamkeit braucht.
Für Hover- oder Active-States musst du selten die Farbe wechseln — ein Sprung um eine Rampenstufe (z. B. von primary-600 auf primary-700) genügt meistens. So bleibt die Farbfamilie konsistent, während der Zustand klar unterscheidbar wird.
Der Farbton (Blau, Grün, Rot) sollte in einem UI immer eine feste Rolle haben. Wenn Blau primär für Aktionen steht, dann nicht gleichzeitig für Informationen — sonst verwässert die Semantik. Weniger Farbrollen, klarer verteilt, ergeben ein stärkeres System als viele Rollen mit unklarer Abgrenzung.
Zwei Farben mit derselben Lightness (im HSL-Sinne) können unterschiedlich hell wirken — Gelb wirkt heller als Blau bei identischer Zahl. Für ernsthafte Farbsysteme lohnt der Blick auf perzeptive Farbräume wie OKLCH oder HCL, die reale Wahrnehmung besser abbilden als HSL. Moderne CSS unterstützt oklch() inzwischen nativ.
Statische Farbdefinitionen sind nur die halbe Miete. Ein Interface lebt von Zuständen — und jede tragende Farbe braucht mehrere State-Varianten.
Für jede interaktive Farbe brauchst du mindestens vier Zustände:
Der Sprung zwischen den Zuständen sollte spürbar, aber nicht dramatisch sein. Eine bewährte Regel: Hover verschiebt um eine Rampenstufe, Active um zwei. So bleibt die Farbfamilie stimmig.
Ein Fehler-Rot hat viele Aufgaben: Feldrand bei ungültiger Eingabe, Hintergrund eines Alerts, Textfarbe einer Fehlermeldung, Icon in einer Toast-Message. Wer nur eine einzige rote Farbe definiert, bekommt Kontrastprobleme — auf hellem Untergrund braucht der Text ein dunkleres Rot als der Feldrand.
Ein sauberes Error-Set enthält typischerweise:
error-50 / error-100)error-500)error-700)error-600)Dasselbe Muster gilt für Success (Grün), Warning (Gelb/Orange) und Info (Blau).
Der Focus-Ring ist keine Detailfrage — er ist das primäre Signal für Nutzer:innen, die per Tastatur navigieren. Er sollte einen hohen Kontrast zur Umgebung haben, ohne die Marke zu verlieren. Häufig genutzt: ein 2-Pixel-Outline in primary-500 mit 2 Pixel Offset zum Element. Details dazu im Artikel zu Barrierefreiheit im UX Design.
Praxis-Tipp: Baue für jede semantische Farbrolle eine kleine „State-Palette" im Design-Tool. Wenn du für Primary nur einen Wert hast, fehlen Hover, Focus und Disabled im System — und werden am Ende improvisiert.
Ein Farbsystem muss heute mindestens zwei Modi tragen. Wer von Anfang mit Rollen und Tokens arbeitet, hat es leicht — wer nachträglich baut, hat oft eine Riesenaufgabe.
Die eleganteste Struktur: Die semantischen Rollen bleiben identisch, die dahinterliegenden Werte ändern sich pro Modus. color-surface-page ist im Light Mode fast weiß, im Dark Mode fast schwarz — der Name bleibt gleich, jede Komponente funktioniert automatisch in beiden Modi.
Ein reines Umdrehen der Helligkeit produziert schlechte Dark-Mode-Paletten. Dark Mode braucht entsättigte Töne, weil hoch gesättigte Farben auf dunklem Grund optisch zu vibrieren scheinen (davon zu trennen ist Halation: das Verschwimmen heller Schrift auf sehr dunklem Grund, das vor allem Menschen mit Astigmatismus trifft). Deine Primary-500 aus dem Light Mode ist im Dark Mode fast immer zu grell. Faustregel: Sättigung im Dark Mode spürbar reduzieren, verbreitete Empfehlungen liegen bei 20 bis 40 Prozent, Helligkeit gezielt anheben.
Alle großen Betriebssysteme bieten seit Langem einen Kontrastmodus. Achtung: Die Windows-Kontrastdesigns setzen über forced-colors eigene Systemfarben durch und überschreiben deine Werte — dort helfen Systemfarben-Schlüsselwörter und sichtbare Ränder, kein eigenes Farbset. Ein drittes Token-Set greift bei prefers-contrast: more, etwa unter macOS und iOS. Aufwand: überschaubar. Wirkung für betroffene Nutzer:innen: enorm.
Ein modernes Frontend erkennt die System-Präferenz per prefers-color-scheme und schaltet automatisch. Wer den Modus zusätzlich manuell anbieten will (Toggle im Header), sollte die Wahl in einem Cookie oder Local Storage speichern — sonst springt jede Session zurück.
Farbe ist ein starkes Design-Werkzeug — und für Millionen Menschen unbrauchbar, wenn sie das einzige Signal ist. Rund acht Prozent der Männer und ein halbes Prozent der Frauen haben eine Rot-Grün-Schwäche. Menschen mit Sehbehinderung sehen Farben teils gar nicht, teils stark reduziert.
Für normalen Text ist ein Kontrastverhältnis von mindestens 4,5:1 vorgeschrieben (Stufe AA; Stufe AAA verlangt 7:1), für großen Text (ab 24 Pixel Regular oder ab 18,66 Pixel Bold, also 14 pt) mindestens 3:1. Für UI-Elemente wie Buttons, Icons und Formular-Ränder gilt ebenfalls 3:1. Prüftools: WebAIM Contrast Checker, Stark, Figma-Plugins wie „Contrast".
Ein rotes „Ungültig"-Feld wirkt für Rotblinde wie jedes andere Feld. Immer ein zweites Signal ergänzen: Text („Bitte eine gültige E-Mail-Adresse eingeben"), Icon (Warndreieck), Rand-Änderung. Rein farbliche Statusanzeigen sind Barrieren.
In Diagrammen ist reine Farbunterscheidung besonders heikel. Nutze mindestens einen zweiten Kanal: Muster (gestrichelt, gepunktet), Symbole an den Datenpunkten, direkte Beschriftung neben der Kurve. Farbpaletten für Data Viz sollten außerdem colorblind-freundlich sein (z. B. Okabe-Ito, Viridis, ColorBrewer).
Der Focus-Ring darf nicht so subtil sein, dass er auf hellen und dunklen Hintergründen verschwindet. Test: Schließe kurz die Augen, navigiere per Tab-Taste durch deinen Screen, öffne die Augen — findest du den Fokus in unter einer Sekunde?
Merksatz für Barrierefreiheit: Wenn dein Interface auch in Schwarz-Weiß funktioniert, funktioniert es für alle. Farbe darf verstärken — nicht das alleinige Signal sein.
Sobald das Farbsystem mehr als eine Person tangiert, entstehen Übergabe-Probleme. Design Tokens sind die einzige nachhaltige Lösung.
Ein vollständiger Token beschreibt Wert, Rolle und optional Metadaten:
color.action.primary.default)Die Palette:
Für ein kleines Team reichen Figma Variables plus eine Convention, wie Tokens ins Frontend kommen. Für größere Systeme lohnt sich Style Dictionary schnell.
Im Web sind CSS Custom Properties (Variablen) das natürliche Zuhause für Farb-Tokens. Sie erlauben Runtime-Wechsel zwischen Modi, sind cascadable und funktionieren in allen aktuellen Browsern. Der Wechsel Light → Dark braucht dann keine JavaScript-Berechnung, sondern nur ein neu gesetztes Wurzel---color-*.
Ein Naming-System, das im Team hält, ist wichtiger als das perfekte System. Bewährt hat sich eine Struktur category.property.variant.state (color.text.primary.hover) oder ein flacheres Muster (color-text-primary-hover). Halte dich an eine Konvention und dokumentiere sie in einer README.
Wenn du diesen Artikel praktisch nutzen willst, geht das in einer halben Stunde — am besten gemeinsam mit Design und Entwicklung. Geh dein Produkt durch und prüfe:
color-action-primary — oder nur rohe Hex-Werte?Eine ehrliche Bestandsaufnahme liefert in fast jedem Produkt fünf bis fünfzehn konkrete Verbesserungen — die meisten davon in einem Sprint umsetzbar, alle mit direkter Wirkung auf Klarheit, Marke und Barrierefreiheit.
Ein Farbsystem ist kein Deko-Layer, sondern die Grundstruktur, mit der dein Produkt Bedeutung transportiert. Farbe zeigt, was interaktiv ist, was Warnung ist, was ruht und was aufmerksam machen will. Wer sie bewusst systematisiert, gewinnt Konsistenz, Wartbarkeit und Barrierefreiheit — und behält gleichzeitig Raum für Markenwirkung.
Die wichtigsten Takeaways:
color-action-primary statt #1d5eff — der Unterschied entscheidet über Wartbarkeit.Ein Produkt mit einem bewussten Farbsystem wirkt anders als eines mit „ein bisschen Primary, ein bisschen Grau und Rot für Fehler". Der Unterschied ist selten spektakulär im ersten Moment — aber er trägt jeden Screen, jede Warnung und jede Interaktion, mit der Nutzer:innen deinem Produkt begegnen.
Transparenzhinweis: Die Bilder in diesem Artikel wurden mit KI erstellt. Der Text wurde mit KI auf Rechtschreibung und Grammatik geprüft. Die redaktionelle Verantwortung liegt bei Jannik Noe.
Design Systems
Von der Komponenten-Inventur bis zur Governance: Ich baue Design Systems, die Teams tatsächlich benutzen — und übergebe sie so, dass sie gepflegt werden.
Warum Typografie in Web und App eine eigene Designdisziplin ist — und wie du Type-Systeme, Hierarchie und Lesbarkeit so aufbaust, dass sie Marke, UX und Performance gleichzeitig stärken
Wie du Formulare in Web- und App-Produkten so gestaltest, dass sie Vertrauen schaffen, Abbrüche reduzieren und barrierefrei funktionieren — vom Input-Feld bis zum Fehlerzustand
Warum Dark Mode 2026 eine eigene Designdisziplin ist — und wie du Kontraste, Farbsysteme und Tokens so baust, dass dunkle Oberflächen in Web und App wirklich funktionieren
Du planst ein digitales Produkt, ein Redesign — oder möchtest euer Team mit einem AI-UX Workshop voranbringen?
Ich unterstütze Unternehmen dabei, komplexe Anforderungen in klare, nutzerfreundliche Lösungen zu übersetzen.