Für Dark Mode und Themes entwickeln

Users increasingly expect dark mode. A visual language built for one theme breaks the moment you flip the background.

This lesson shows how to design a palette that adapts across themes without duplicating your entire style guide.

Instead of using white for backgrounds, define semantic roles: surface, text-primary, border.

Each role maps to a different literal value per theme. The component references the role, so it adapts automatically when the theme changes.

A theme is just a lookup table from role to color. Light and dark themes share the same role names but different values.

The snippet shows the idea.

A common mistake is to simply invert colors. Pure black on pure white inverted becomes harsh and causes eye strain.

Good dark themes use dark grays (not #000000) and slightly dimmed text to reduce glare. Design each theme intentionally.

In light mode, shadows imply elevation. In dark mode, shadows are nearly invisible, so elevation is shown with lighter surface colors instead.

A raised card in dark mode is a slightly lighter gray than the page behind it. Plan surface tints for each elevation level.

Accessibility contrast ratios must hold in both themes. A text color that passes on white may fail on dark gray.

Check every semantic pairing (text on surface, text on primary) against WCAG AA in each theme before shipping.

Your brand accent often needs adjusting per theme. A vivid blue that pops on white can feel oversaturated on dark backgrounds.

Define theme-specific accent values so the brand feels intentional, not accidentally neon, in dark mode.

Most platforms expose a user preference via prefers-color-scheme. Default to the system setting, then let users override.

Respecting the OS choice means users land in their preferred theme automatically - a small detail that feels polished.

Photos and illustrations designed for white backgrounds can clash in dark mode. Provide theme-aware assets or add subtle borders/overlays.

Logos especially may need a light variant. Plan asset variants as part of your visual language, not as an afterthought.

Every new component must be reviewed in both themes before merging. A component that looks great in light mode can be unreadable in dark mode.

Build a theme toggle into your documentation so reviewers can switch instantly.

Designing semantic, theme-aware colors from the start makes adding future themes - high contrast, seasonal, white-label - far cheaper.

The visual language stays the same; only the value tables change.

You learned to extend a visual language across themes:

• Use semantic color roles, not literal values.
• Design dark mode intentionally - it is not inversion.
• Show elevation with surface tints and verify contrast in every theme.
• Respect system preference and provide theme-aware assets.

A semantic palette makes multi-theme support a configuration, not a rewrite.