WhollySoftware
Back to blogDesign

Designing for Dark Mode From the Start Instead of Retrofitting It

Wholly Software TeamJuly 3, 20256 min read
Designing for Dark Mode From the Start Instead of Retrofitting It

A media streaming client asked us to add dark mode to their app about eight months after the light-mode-only version had shipped, and our first instinct, inverting the existing color values programmatically, produced results that were technically dark but visually wrong in specific ways: shadows that had made cards feel elevated in light mode became muddy and indistinct on a dark background, and a light blue accent color that worked fine on white became nearly illegible against near-black.

We ended up redesigning the color system properly rather than inverting it, which meant defining elevation in dark mode through subtle lightness steps in the surface color itself, lighter grays for elements meant to feel closer to the user, rather than through drop shadows, which mostly stop reading as depth once the background is already dark. This is a genuinely different technique from light mode's elevation system, not a palette swap of the same technique.

Accent and brand colors needed independent tuning too, not a single value used identically in both modes. The client's saturated brand orange worked well on white but felt aggressive and slightly glowing against a dark background, so we shifted it slightly less saturated and a touch lighter specifically for dark mode, close enough to still read as the same brand color, different enough to sit comfortably on the darker surface.

Once we internalized how much rework a retrofit costs, we changed our default process for new projects: every color token now gets defined as a pair, a light-mode value and a dark-mode value, from the very first palette exploration, even on projects where dark mode isn't in the initial launch scope. It costs relatively little extra time during initial design and saves a full redesign cycle later if dark mode gets requested, which on our client base, it usually eventually is.

The instinct to treat dark mode as a color inversion is understandable, since it's the cheapest possible interpretation of the request, but it consistently produces a worse result than designing dark mode as its own considered system built from the same underlying tokens as light mode. Two systems sharing structure, not one system wearing an inverted filter.

Dark ModeDesign SystemsColorUX
Designing for Dark Mode From the Start Instead of Retrofitting It — Wholly Software