Ask most teams for a dark mode and they start the same way: flip the background and text colors of the light-mode screens and call it done. A few days of real use later, the cracks show up one by one — shadows that look wrong, brand colors that turn muddy, images with edges that seem to float above the page. Dark mode isn’t a color-inversion exercise. It’s a full redesign for a different lighting condition.
1. Why a Simple Inversion Falls Apart
In light mode, a drop shadow tells the eye that a surface is floating above the background. On a dark background, a black shadow barely registers, so the same trick can’t carry the same hierarchy. Dark interfaces typically swap shadow for elevation instead — a surface reads as “higher” because it’s a lighter shade of gray, not because it casts a shadow.
Saturated brand colors cause a second problem. A pure, high-chroma color placed on a near-black background seems to vibrate and tires the eye quickly, so dark mode needs its own set of tones with the lightness and saturation pulled back rather than reused as-is.
Dark mode became a system-level option on both iOS and Android for practical reasons, not just aesthetics. OLED displays render black by switching pixels off, so a darker interface can meaningfully reduce power draw, and lower brightness is easier on the eyes in dim or nighttime settings. Because it’s baked into the operating system rather than treated as a bonus feature, dark mode is a design problem to plan for, not a toggle to bolt on later.
Light Mode
Hierarchy comes from drop shadows, and saturated brand colors can be used as-is against a bright background.
Dark Mode
Hierarchy comes from surface brightness instead of shadow, and colors need their own lightness- and saturation-adjusted tones.
2. Rebuilding the Color System
A dark mode that actually works starts from its own set of color tokens, separate from light mode. Background, surface, text, and accent colors each need a light value and a dark value, wired so the interface can switch between them automatically in code. Teams that have already built a color system around semantic names and lightness steps find this step becomes a matter of swapping values, not rebuilding the palette from scratch.
Two token sets are necessary because light and dark aren’t just different colors — the direction of contrast itself reverses. Light mode is dark text on a bright surface; dark mode is the opposite. Forcing both into a single shared color value breaks the contrast on one side or the other every time. The same restraint that lets a brand like MUJI unify a sprawling product line around quiet, material-true tones rather than loud primaries applies just as well to a dark palette — muted mid-tones tend to hold together across a whole interface better than saturated color ever does.
3. Don’t Forget Images, Icons, and Type
If only text and background get the dark-mode treatment, a white-background logo or screenshot ends up sitting on the page as a glaring bright rectangle. The same contrast checklist used for accessibility elsewhere in the product should be re-run against the dark palette, since a combination that passed in light mode can quietly fail once the background flips.
Typography needs a second look too. Thin type on a dark background triggers a halation effect that makes the same weight look thinner than it does on a light background, so body text can end up looking either smudged or too faint to read comfortably. Nudging body copy slightly bolder than the light-mode weight, and using an off-white rather than pure white for text color, goes a long way toward reducing eye strain.
Export white-background logos and screenshots as transparent PNGs rather than reusing the light-mode asset as-is.
Add a subtle border around images so the edge doesn’t read as a hard, floating rectangle.
Thicken icon stroke widths slightly for dark mode so linework doesn’t dissolve into the background.
💡 Pro tip — Trade shadows for surface brightness to carry hierarchy, and build a dedicated dark-mode tone for every saturated brand color instead of reusing the light-mode value. Both changes do a lot to cut visual fatigue.
4. System Switching or a Manual Toggle
How dark mode gets exposed to users is an easy decision to overlook. A product could simply follow the operating system’s setting, or it could add its own toggle inside the app — but in practice, supporting both is the safer route: default to the system setting, while still letting a user pin the app to light or dark regardless of what the OS says.
Follow System Setting
Consistent with the rest of the device, but a user can’t force their preferred mode inside the app itself.
In-App Toggle
Users choose directly, but it adds a settings item and forces a decision about what the default should be.
A common mistake is putting off this decision until the two approaches end up half-mixed — some screens following the system setting, others locked by a manual toggle, so the same screen appears in a different mode depending on when it’s opened. Settling this before the color tokens are built saves a much bigger rework later.
Closing thoughts
Treat dark mode as a color inversion and the result always feels slightly off somewhere. Treat it as its own lighting condition and rebuild the color tokens from that premise, and dark mode stops being an add-on option — it becomes another face of the brand. Apple’s dark mode Human Interface Guidelines lay out this redesign mindset in more detail for anyone building one from scratch.
Design Daily Life · Notes on design, daily