Light vs Dark Designing Apps That Look Great in Any Mode

Your app launches on a Thursday. By Friday morning, a third of the people who downloaded it are using it in bed, in the dark, with their phone brightness turned down. They have switched to dark mode at the OS level, and your product has followed their phone into that context. The question is whether you designed for that moment or simply hoped the colours would hold up.

Designing for both modes means making real decisions about how your product feels in every context a real user inhabits.

Light and dark mode stopped being an optional extra the moment operating systems began honouring them automatically. An app that looks considered in one mode and broken in the other tells the user something about how much the product cares. That impression forms fast. Research by Lindgaard et al., 2006 found that users form a visual impression in as little as 50 milliseconds, before they have read a word or tapped a button. By the time they are conscious of thinking anything, they have already decided whether the product feels trustworthy.

What follows is a design guide to the decisions that sit behind the implementation: what changes psychologically when the background goes dark, how colour, contrast, type, and elevation behave differently, and how to build a system that holds up in either context without compromise.

Why Mode Is a Design Decision, Not a Developer Toggle

The most common mistake teams make with dark mode is treating it as an engineering task. A developer swaps background and foreground tokens, checks that text remains readable, and marks the ticket done. The result is technically a dark mode, but it is usually the wrong dark mode, because the emotional register of a dark UI is not just an inverted light UI.

Dark and light are not mirror images of each other. Light mode carries associations with clarity, openness, and daytime productivity. Dark mode carries associations with depth, focus, and reduced stimulation. These are different moods, and a product that simply flips its colours without thinking about those associations misses the point of the choice entirely.

On the healthcare and health insurance product we built for African markets, we chose a dark UI with green undertones as a deliberate emotional decision. The users arriving at that product were often in an anxious state, dealing with health concerns or insurance queries that already carried stress. A bright white interface would have felt clinical and cold. The dark background with warm green undertones communicated calm and safety before the user had read a single line of copy.

Mode is a design decision because it shapes the emotional experience of the product. The implementation follows from that decision. The decision never follows from the implementation.

How Contrast Ratios Affect Readability and Perceived Quality

Contrast ratio is the single most consequential technical variable in both light and dark mode design, and it is the one most often handled carelessly. The WCAG minimum for body text is a 4.5:1 contrast ratio against its background. Below that threshold, reading becomes effortful. Users do not always notice the effort consciously, but they feel it as fatigue, and they attribute the fatigue to the product rather than to the text colour.

In light mode, poor contrast usually means text that is too light grey on white. In dark mode, the failure is more varied: text that is pure white on pure black (which creates a halation effect that most people find tiring on long reads), coloured text on dark backgrounds that loses separation, and ghost text in input fields that disappears entirely.

Contrast also shapes perceived quality. A product where every text element clears the accessibility threshold looks more considered than one where half the UI is technically compliant and the rest is a guess. According to Build Grow Scale, contrast ratio at that 4.5:1 minimum affects conversions 3.2x more than specific colour choice, which is a useful reminder that the structural decisions matter more than the palette.

Test contrast ratios in both modes against actual device screens, not just design tool previews. OLED screens make dark mode colours behave differently from LCD, and a ratio that passes on one display can fail on another.

Off-white on near-black, rather than pure white on pure black, reduces halation while maintaining high contrast. That small shift makes dark mode comfortable for long reading sessions.

Colour Temperature and the Emotional Register of Each Mode

Colour temperature describes how warm or cool a colour feels, and it behaves differently depending on what surrounds it. A warm amber on white reads as cheerful and approachable. The same amber on a dark background reads as glowing and premium. Neither is wrong, but they are not the same emotional signal, and designing a colour system without thinking about temperature in both contexts produces unexpected results.

On the healthcare product we designed for African markets, green was the central colour choice, and it was chosen for a specific psychological reason. Green carries associations with safety, medical support, and calm across a wide range of cultural contexts. On a dark background, those green undertones felt grounded rather than clinical, which was exactly the emotional register the product needed. A cooler blue might have read as more medical and sterile, which would have increased rather than reduced user anxiety.

The same colour delivers a different emotional signal on a dark background than it does on a light one.

This is the core design question for colour temperature in dual-mode products: which emotional register does each mode need to deliver, and does your palette support that on both backgrounds? A product that uses a single brand colour without adjusting its warmth, saturation, or luminosity for each mode will almost always feel slightly off in one of them. The colour is present but the feeling is wrong, and users sense that discrepancy without being able to name it.

Saturated colours generally need to come down slightly in dark mode, where high saturation reads as harsh. Warm tones often need a small shift toward their mid-range to avoid reading as orange-heavy against dark backgrounds.

Typography and Hierarchy Behave Differently in Light and Dark

Type hierarchy in light mode is built through a combination of weight, size, and colour. A heading is large and dark, a subheading is medium and grey, body text is regular and slightly lighter still. That system works well on white because the background provides a consistent neutral baseline from which all the greys can be distinguished.

In dark mode, that hierarchy collapses if it is simply inverted. Grey on dark is not the visual equivalent of grey on light: the same grey value that reads as a clear secondary label on white can nearly disappear on a dark background. Teams often discover this late in development when they realise their secondary and tertiary text colours are indistinguishable from each other in dark mode, and they end up bumping every value up toward white, which destroys the hierarchy they were trying to create.

The fix is to build a separate dark-mode type scale rather than inverting the light-mode one. Where light mode uses three values of grey for its hierarchy, dark mode typically needs the same three values mapped to a different range, often running from a near-white for primary text down to a noticeably brighter mid-grey for secondary text than the equivalent light-mode value.

For long-form reading in dark mode, a slightly warm off-white for body text (such as a very pale cream) reduces eye strain compared to pure white, and gives the typography a more refined quality than a flat 100% brightness setting.

Font weight is also worth revisiting across modes. Light or thin weight fonts that read elegantly on white backgrounds can feel insubstantial on dark ones. Stepping up a font weight in dark mode is a simple adjustment that makes a measurable difference to readability and perceived quality.

Trust, Tone, and When Dark UI Is the Right Clinical Choice

Dark mode carries a reputation as the preference of developers, gamers, and people who work late. That association is real but limiting. Dark mode is also a legitimate choice for products where the emotional context calls for seriousness, focus, or calm, and making that choice deliberately produces better products than defaulting to light because light is familiar.

On the healthcare and health insurance product for African markets, we made a conscious decision to go dark. The users arriving at the product were often dealing with health concerns, navigating insurance questions they did not fully understand, or checking on family members. A light, bright interface in that context would have felt mismatched. The dark background with green undertones, combined with simplified language that stripped out medical jargon entirely, created an experience that reduced anxiety rather than amplifying it.

The language decisions mattered as much as the colour decisions. We simplified every piece of copy in the product so that users felt looked after and understood, not tested or confused. Dark UI paired with clinical language would have felt cold. Dark UI paired with warm, plain language felt supportive. The mode sets the emotional context, and the rest of the design either reinforces or contradicts it.

• Finance and trading products often use dark mode to signal seriousness and focus
• Health and wellness products can use dark mode to reduce stimulation and anxiety
• Media and entertainment products use dark mode to let content take visual priority
• Productivity tools use dark mode to reduce eye strain during long sessions

The question is never which mode looks better in the abstract. It is which mode serves the emotional state of the user at the moment they are using the product.

Elevation, Shadows, and Depth Without a White Background

In light mode, elevation is communicated through shadows. A card floats above its background because it casts a shadow on the surface below it. This system works because shadows are darker than light backgrounds, so the depth signal is clear. In dark mode, that system breaks down: dark shadows on dark backgrounds are invisible, which means the entire visual language of elevation has to be reconsidered.

The solution that Material Design codified, and which holds up well in practice, is to communicate elevation through lightness rather than shadow. In dark mode, a component that floats above the base layer appears slightly lighter than the background, not darker. The higher the elevation, the lighter the surface. This reverses the light-mode convention but produces a coherent depth system that reads naturally.

Layering Surface Colours

A dark-mode surface scale typically runs from the darkest background at the base, through progressively lighter values for cards, modals, and tooltips. Four to five steps is usually enough to cover all the elevation scenarios a standard app needs. Each step should be distinguishable but not jarring, which in practice means steps of about 4 to 8% lightness.

Where Shadows Still Work

Soft shadows with low opacity and a slight warm or cool tint can still add dimensionality in dark mode without disappearing entirely. A shadow at 15% opacity with a slight blue tint reads as depth on a dark background in a way that a pure black shadow does not. Used sparingly and beneath elevation cues rather than instead of them, they add polish without noise.

Colour Palettes That Actually Work Across Both Modes

Building a colour palette that works across both modes starts with accepting that a single set of values will not do the job. Most brand colour systems are built against a light background, which means the primary brand colour, the accent colour, and the semantic colours (error red, success green, warning amber) have all been tuned for a context that dark mode removes.

According to ASOMobile, over 50% of users regularly use dark mode, which means a palette that only works well on light backgrounds is already failing a significant portion of the people using the product. The practical response is to define colour tokens at two levels: the base palette, which contains all the raw colour values, and the semantic layer, which maps those values to roles (background, surface, primary, on-primary, error, on-error) and provides separate mappings for each mode.

Semantic colours need checking in both modes individually. Error red that meets contrast requirements on white can easily fail on a dark surface, and the fix is not to use a different red on principle, but to adjust the lightness of that specific token for the dark context.

Designing System Components That Hold Up in Either Context

Individual colours are one problem. System components are another. A button, an input field, a toggle, a badge, a modal: each of these is a small design system in itself, and each needs to be considered in both modes as a complete unit rather than as a set of values to flip.

Input fields are one of the most frequently broken components in dark mode. In light mode, an input typically has a light grey fill and a slightly darker border. In dark mode, that fill needs to be lighter than the background surface it sits on, which is the opposite of the light-mode convention, and the border needs enough contrast against both the fill and the background to be visible without being harsh. Getting that wrong produces inputs that either disappear into the background or look like they are floating without a container.

Buttons and Interactive States

Button hover, pressed, and focused states all need to be re-examined in dark mode. A hover state that uses a slight darkening of the button colour works in light mode. In dark mode, darkening a button surface often makes it look disabled rather than active. Lightening the button on hover reads more naturally as an interactive signal in a dark context.

Build components in your design tool with both mode states visible side by side before finalising values. What looks fine in isolation often reveals a problem when the two versions are compared directly.

Icons and Illustration

Line icons exported as SVGs with a fixed dark stroke will disappear on dark backgrounds unless the fill or stroke colour is tokenised to the foreground role. Flat illustrations built for light mode almost always need a dark-mode variant, particularly if they contain white areas that are invisible on dark backgrounds or very light tints that lose their distinction against a dark surface.

Testing and Validating Both Modes as Distinct Experiences

The most common testing failure with light and dark mode is testing them sequentially rather than simultaneously. A designer checks the light mode build, approves it, then checks the dark mode build and approves it, and the two approvals happen hours or days apart. By the time the dark mode is reviewed, the light mode is already out of mind, and small inconsistencies between the two do not register.

Testing both modes as distinct experiences means treating them the same way we would treat two separate products: each gets a full review of every screen, every component state, and every user flow. The criteria are "does this screen feel right, does the hierarchy read clearly, does the mode match the emotional context of this feature."

Real-device testing is non-negotiable. Design tool previews and browser-based simulators do not accurately represent how dark mode looks on OLED screens, where true blacks create a level of contrast that can make lighter surfaces glow in ways that appear too bright. On AMOLED displays, the jump between the true-black background and a dark grey surface can be more pronounced than expected, making elevation decisions that looked subtle in the preview look quite obvious on screen.

1. Review every screen in light mode to approve it as a complete experience
2. Review every screen in dark mode as a separate, equally complete experience
3. Compare equivalent screens side by side to catch tonal inconsistencies
4. Test on at least one OLED device and one LCD device
5. Run both modes through WCAG contrast checking on every text element

User testing across both modes is worth running separately if budget allows, because users who primarily use dark mode have calibrated their expectations around it, and their feedback on a dark-mode experience is sharper than feedback from someone who only encounters it during a test session.

Conclusion

Designing for both light and dark mode well is a commitment to the full range of contexts in which real people use your product. A user in a dark room, a user with light sensitivity, a user who simply prefers the aesthetic of dark surfaces: all of them deserve an experience that feels considered rather than tolerated.

The healthcare product we built for African markets demonstrated that mode is a genuine emotional lever. The decision to go dark with green undertones, paired with simplified language, shaped how users felt at a moment when they were already stressed. That was a design decision, not a development setting, and it made a real difference to the experience.

The structural work of building a dual-mode system, defining semantic tokens, adjusting contrast and weight and elevation for each context, checking every component in both states, is genuinely more work than designing for one mode. But the alternative is a product that works well in one context and feels neglected in another, and users notice that neglect even when they cannot articulate it.

Start with the emotional register each mode needs to deliver. Let the colour, typography, and elevation decisions follow from that. Test both as complete experiences rather than variations of the same one. And check everything on a real device before signing off.

If you are building a product and want to think through how light and dark mode decisions fit into your broader design system, let's talk about your app design.

Frequently Asked Questions