Dark mode ships at v2—40% still hunt for the toggle

You've shipped dark mode. The toggle is in settings, the CSS variables are wired up, and the release notes went out. Six weeks later, your analytics show roughly 40% of users still scrolling through menus looking for it—or bouncing to Google to ask where it lives. So what's going on? This isn't a UI bug. It's a story about how people make decisions when they're uncertain, and what happens when a preference they can't quite name collides with an interface that expects them to know exactly where to look.

The toggle isn't hidden, it's just not where the brain expects it

Most teams treat discoverability as a layout problem: put the toggle in settings, label it clearly, done. But users don't scan settings menus systematically. They arrive with a mental model built from every other app they've used, and that model is wildly inconsistent. iOS puts appearance under Display & Brightness. Android buries it in Display. Some apps surface it in the profile menu, others in a quick-settings panel, others only via the system theme.

When your toggle doesn't match the model a user has in their head, they don't conclude "I should search more thoroughly." They conclude "this app probably doesn't have it." That's a decision made under uncertainty, and it's shaped by something psychologists call satisficing—Herbert Simon's term for choosing the first option that seems good enough rather than exhaustively searching. A user who's looked in two plausible places and found nothing will often stop, not because they've confirmed absence, but because the expected cost of more searching now outweighs the expected benefit.

This is why "we shipped it, they should find it" fails. The toggle's existence is not the same as its availability in the user's decision process.

Variable rewards explain why some users keep hunting and others give up

Here's where it gets interesting. Behavioural psychology has a well-documented finding: behaviour that's reinforced inconsistently is more persistent than behaviour reinforced every time. This is variable-ratio reinforcement, and it's usually discussed in the context of why people keep pulling a lever or refreshing a feed. But it has a quieter implication for interface design.

If a user has previously found a useful setting buried in an unexpected place—say, a reading mode they stumbled on three menus deep—they learn that hunting sometimes pays off. That user will keep digging. A different user, one who has mostly found settings exactly where expected, learns the opposite: if it's not obvious, it's not there. Same app, same toggle, radically different search behaviour, driven entirely by prior reinforcement history.

The 40% figure isn't a monolith. It's probably a mix of people who looked once and quit, people who looked in the wrong place and assumed absence, and a smaller group who genuinely can't find it because your information architecture is fighting their expectations. Segmenting by behaviour—did they open settings at all? how many screens did they visit?—tells you which problem you actually have.

Loss aversion makes the missing toggle feel worse than it is

There's a second force at work, and it's the one that turns mild inconvenience into a support ticket. Kahneman and Tversky's work on loss aversion showed that losses loom larger than equivalent gains. In interface terms: a user who wanted dark mode and couldn't find it doesn't experience the absence as neutral. They experience it as a small loss—of comfort, of the expectation your release notes set, of the sense that the app respects their preferences.

That asymmetry matters because it changes what people do next. A neutral unmet preference gets shrugged off. A perceived loss gets acted on: they email support, they leave a review, they mention it to a colleague. The volume of "where's the toggle" complaints is almost always disproportionate to the actual friction, because the friction is being amplified by the framing. Your release notes said "dark mode is here." The user's experience says "dark mode is here for other people." That gap is the loss.

The practical upshot: discoverability problems don't scale linearly with how hidden something is. A toggle that's 30 seconds of searching away can generate as much frustration as one that's genuinely absent, because the user knows it exists and can't reach it. That's a worse feeling than not knowing it existed at all.

What actually moves the number

If the problem is expectation mismatch plus loss amplification, the fix isn't "make the toggle bigger." It's reducing the search cost and closing the gap between promise and reach.

Match the platform, not your design system. If most of your users are on iOS, put appearance where iOS puts it. Fighting the platform's conventions to keep your settings menu internally consistent is a losing trade—you're optimising for your mental model, not theirs.

Offer a second path. A single toggle in a single location is a single point of failure. A quick-access control in the header, a keyboard shortcut, or a prompt on first launch ("prefer dark mode?") gives users multiple routes to the same outcome. Redundancy isn't inelegant here; it's how you accommodate the fact that people search differently.

Use the release notes to teach location, not just existence. "Dark mode is here—find it under Settings > Appearance" does more work than "Dark mode is here." You're not just announcing a feature, you're seeding the mental model that makes it findable next time.

Instrument the search, not just the outcome. Track how many users open settings and leave without toggling. Track time-to-find for those who do. That data tells you whether you have a discovery problem, a labelling problem, or a "they found it and didn't want it" problem—three very different situations that all look like the same 40% in a dashboard.

Where this goes next

The deeper pattern here is that interface decisions are behavioural decisions, whether or not teams frame them that way. Every default, every location, every label is a nudge—sometimes a helpful one, sometimes one that quietly tells users their preferences are a scavenger hunt. The teams that get this right stop treating discoverability as a post-launch metric to be monitored and start treating it as a design input: where will people look first, what will they conclude if they don't find it, and what does that conclusion cost them?

For your next release, the question worth asking before you ship isn't "is the feature there?" It's "when a user decides they want this, what's the first place they'll check—and are we there?" If the answer is no, you already know what your 40% is going to look like.