Bild: Mit KI generiert

Dark Mode Design wird in vielen Projekten so behandelt: Am Ende des Designprozesses wird eine zweite Farbpalette erstellt, Weiß wird zu Schwarz, Hellgrau zu Dunkelgrau, und fertig ist der Dark Mode. Das Ergebnis sieht häufig nicht nur nicht gut aus, sondern es lässt sich auch schwer warten.

Der Grund liegt nicht in mangelnder Sorgfalt, sondern in einem konzeptuellen Fehler: Dark Mode wird als Farbvariante behandelt, obwohl er ein eigenständiges Farbsystem erfordert. In 2026 behandeln Apps, die Dark Mode wirklich gut umsetzen, ihn als erste Design-Oberfläche, nicht als nachträgliche Anpassung.

In diesem Artikel erfährst du, warum direkte Farbinvertierung strukturell scheitert, wie Elevation in Dark Mode ohne Schatten kommuniziert wird, und warum semantische Design Tokens der einzige wartbare Weg sind, beide Modi konsistent zu halten.

 

Warum direkte Invertierung nicht funktioniert

Die Invertierung eines Light-Mode-Designs produziert in der Regel drei typische Probleme, die alle auf denselben Grundfehler zurückgehen: Das Farbsystem wurde für Helligkeit optimiert, nicht für Dunkelheit.

 

Schatten verschwinden. Im Light Mode kommunizieren Schatten Elevation — eine Card, die über dem Hintergrund schwebt, wirft einen Schatten nach unten. Im Dark Mode funktioniert das nicht mehr. Dunkle Objekte auf dunklem Hintergrund können keine sichtbaren Schatten nach unten werfen. Wer das invertierte System beibehält, verliert die gesamte Tiefeninformation des Interfaces.

 

Gesättigte Farben wirken zu intensiv. Eine Primärfarbe, die im Light Mode auf weißem Hintergrund gut lesbar ist, kann auf dunklem Hintergrund unangenehm leuchtend wirken. Das liegt an der veränderten Wahrnehmung von Farbsättigung: Auf dunklen Oberflächen erscheinen gesättigte Farben visuell schwerer und intensiver als auf hellen. Material Design 3 adressiert das durch ein tonbasiertes Farbsystem, in dem jede Farbrolle — Primary, Secondary, Tertiary — eine eigene Helligkeitsstufe für Dark Mode hat.

 

Pure Black erzeugt Lesbarkeits- und Bewegungsprobleme. Reines Schwarz (#000000) als Hintergrundfarbe in Dark Mode ist auf OLED-Displays technisch interessant, weil schwarze Pixel ausgeschaltet sind und keine Energie verbrauchen. Es erzeugt aber beim Scrollen auf manchen Geräten einen sogenannten Smearing-Effekt, bei dem helle Textelemente kurz nachleuchten. Apples Human Interface Guidelines empfehlen deshalb dunkelgraue statt reiner schwarzer Hintergründe für die meisten Dark-Mode-Oberflächen. Material Design 3 arbeitet mit #141218 als Standard-Hintergrundfarbe.

 

Elevation ohne Schatten: Das Prinzip dahinter

Im Light Mode wird Elevation durch Schatten kommuniziert. Im Dark Mode wird Elevation durch Helligkeit kommuniziert. Das ist der fundamentale Systemwechsel, der bei der Invertierung verloren geht.

Material Design 3 implementiert das über Surface Tints: Jede Elevationsebene erhält einen weißen Overlay mit steigender Deckkraft. Eine Karte auf Elevation Level 1 hat einen Overlay von etwa 5 %, auf Level 3 bereits 11 %, auf Level 5 schon 14 %. Das Ergebnis: Höher gelegene Elemente wirken heller, niedrigere Elemente dunkler. Tiefeninformation entsteht durch Helligkeit, nicht durch Schatten.

Apples Approach ist ähnlich strukturiert, aber anders benannt. Das iOS-Schichtensystem unterscheidet zwischen Base, Elevated und Overlay-Ebenen, die sich im Dark Mode jeweils in ihrer Helligkeit unterscheiden. Semantische Systemfarben wie secondarySystemBackground oder tertiarySystemBackground wechseln automatisch zwischen Light und Dark Mode. Sie sind in iOS nicht als statische Hex-Werte definiert, sondern als adaptive Farbwerte, die das System kontextabhängig auflöst.

Das hat eine direkte Konsequenz für das Figma-Design: Wer im Dark Mode manuell Helligkeitsstufen einträgt, arbeitet gegen das System. Wer mit semantischen Farben und Modi in Figma Variables arbeitet, bildet das Systemverhalten korrekt ab.

 

Farbsättigung in Dark Mode: Der häufig übersehene Aspekt

Auch wenn Elevation richtig gelöst ist, bleibt ein weiteres Problem bestehen: Primär- und Akzentfarben, die für Light Mode definiert wurden, wirken im Dark Mode häufig zu intensiv.

Der Grund liegt in der Helligkeitswahrnehmung. Im HSL-Farbraum bedeutet eine hohe Sättigung bei niedrigem Helligkeitswert ein intensiv leuchtendes Erscheinungsbild auf dunklem Untergrund. Material Design 3 löst das durch das Tone-System: Jede Farbe wird als Skala von 0 (Schwarz) bis 100 (Weiß) definiert. Im Light Mode wird für Primary-Buttons ein Tone von rund 40 verwendet — kräftig genug für weißen Text, gesättigt genug für Wiedererkennbarkeit. Im Dark Mode wird für denselben Button ein Tone von rund 80 verwendet — deutlich heller, aber gleichzeitig weniger gesättigt, weil höhere Tones naturgemäß weniger chromatisch intensiv wirken.

Wer ohne ein solches Tonsystem arbeitet, muss Dark-Mode-Farben manuell kalibrieren. Das kostet Zeit und erzeugt häufig inkonsistente Ergebnisse zwischen verschiedenen Farbfamilien des Systems.

 

Semantische Tokens als einziger wartbarer Weg

Ein Dark Mode, der ohne semantische Tokens gebaut wird, ist schwer zu warten. Jede Farbentscheidung muss doppelt dokumentiert und doppelt angepasst werden. Einmal für Light, einmal für Dark. Bei jedem Rebranding, jedem neuen Brand-Theme oder jeder Accessibility-Anpassung verdoppelt sich der Pflegeaufwand.

Semantische Design Tokens lösen dieses Problem strukturell. Eine Variable wie color/background/primary zeigt im Light Mode auf gray-50 und im Dark Mode auf gray-900. Die Komponente, die color/background/primary referenziert, muss nicht angepasst werden — nur der Wert hinter dem Token ändert sich, je nach aktivem Mode.

Das bedeutet in der Praxis:

• Komponenten werden einmal gebaut und referenzieren ausschließlich semantische Tokens
• Primitive Tokens (die rohen Farbwerte) werden für jeden Mode einmal definiert
• Ein Mode-Switch in Figma Variables aktualisiert das gesamte Interface sofort und konsistent
• Accessibility-Anpassungen wie erhöhte Kontraste können als separater Mode angelegt werden, ohne Komponenten anzufassen

Ohne diese Struktur ist Dark Mode kein System — es ist eine zweite Designdatei, die synchron gehalten werden muss.

 

Was Dark Mode für Mobile App Design konkret bedeutet

Im Kontext des Mobile App Designs kommen zwei zusätzliche Faktoren hinzu, die Dark Mode zu mehr als einem visuellen Thema machen.

Erstens: Leistung auf OLED-Displays. Google hat bestätigt, dass YouTubes Dark Mode auf OLED-Geräten bei voller Helligkeit 43 % weniger Energie verbraucht als der Light Mode. Das ist kein Design-Argument — es ist ein Produktargument, das in App-Projekten mit entsprechenden Zielgruppen relevant wird.

Zweitens: Systemkonsistenz. iOS und Android haben unterschiedliche Dark-Mode-Implementierungen, wie der iOS vs. Android Artikel zeigt. Wer das ignoriert und ein plattformübergreifendes Dark-Mode-Design als einheitliches System behandelt, riskiert Inkonsistenzen mit systemnativen Elementen: besonders bei Dialogen, Navigation Bars und systemgeneriertem Text.

 

Take Away Message

Dark Mode Design scheitert häufig nicht an fehlender Sorgfalt, sondern an einem konzeptuellen Missverständnis: Es wird als Farbvariante behandelt, obwohl es ein eigenständiges Farbsystem erfordert. Elevation funktioniert über Helligkeit statt Schatten. Gesättigte Farben brauchen im Dark Mode andere Tonstufen als im Light Mode. Und der einzige Weg, beide Modi wartbar zu halten, führt über semantische Tokens, nicht über doppelte Farbpaletten. Wer das von Anfang an als Systemfrage behandelt, baut einen Dark Mode, der bei Rebranding, neuen Brand-Themes und Accessibility-Anpassungen trägt.