> One of the most common UX mistakes is designing UI around the underlying data model instead of user goals.

It's far worse to give users a false mental model of the system. If the underlying system is complex, but that's out of your control, then it will create confusion and frustration in users to paper over it. Please don't do this!

That is, unless you can create a nearly leak-free abstraction. The example given in the article is anything but leak-free.

(This kind of design error reminds me of the skeuomorphism debate nearly a decade ago. Though I do miss beautifully detailed app icons and overall whimsy, in-app false affordances and leaky abstractions both give users an incorrect mental model of the system.)

There’s no better way to ruin usability than to hide how the system actually works in an effort to make it “easier”.

Make it as simple as possible, but no simpler. Anything else is deceptive.

OMG, please no. Make it very obvious which of the three possible behaviors is active. Trying to compress that into just two options is utterly confusing and hard to interpret, especially when it depends on what's the current system theme. It's quite annoying/embarrassing when I switch to dark mode on a night flight, and then one website just blasts the nearby passengers because it just chooses to do light mode anyway for some "smart" reason.

The most important thing is to default to the user’s system setting.

Then you (and your users) only need the toggle, if at all, for edge cases.

(If the user cares, they likely will have set system settings the way they like them, and if they don’t care to, it’s pretty unlikely your web site is special to them. It would really just be for users who care but are somehow forced to use a system that doesn’t support the settings they want, and for dev/testing.)

But I agree with the conclusion of the article. If you do have a toggle, it makes more sense to just have the two options. Users click it to say, “I want it the other way right now.” After that, it makes a lot more sense to assume they want it to keep being the way they want than not. And how do you know what that is? Because they’ve taken the time to specify that in the system settings. Or they haven’t. Because they didn’t care to. In which case you still aren’t doing something they didn’t want.

A UI where you just whack it until it does what you want (and then keeps doing it) is perfect for we tailless monkeys. One where you have to stop what you’re doing to think about your previous life choices and whether you ought to continue to make them is maybe a little too much for each web site.

I might be missing something, I read both articles and do not understand the issue with 3 options. People interact with the theme change maybe once a year or so, a tiny amount of friction in that case is a non issue if that makes it simpler for the user to actually set the theme value they want (system default, light, dark). It really feels that they started with the idea that it should be 2 options, then try to come up with an argument

Letting the system do things for the user is risky enough. Taking away the unambiguous way to turn the automatism on and off just adds insult to injury. This suggestion is not simplification, it is complication.

Personally I'm totally fine with light/dark/auto but if you really must simplify I see only two true ways:

1. Just offer light and dark. No auto. Whether auto works is out of your control anyway. Users who know and want auto have to switch manually.

2. Just offer auto on/off. Default is off and off is light mode. User who want dark mode will figure out how to configure their system.

Isn't the actually-simple answer here "Pick a default. If the user agent specifies a preference, respect it."

Now there's no UX, it just does something reasonable regardless, and if the user has already opted in to color mode management, it respects their declared choice.

Users who are power user enough to want to override their light/dark mode setting per-site can use a browser extension to let them do exactly that on the websites they want to target.

Am I missing something?

this all seems to fall into trap of most UI design writing, where people write blog posts about what users want, what users think, and what users understand, without actually doing any user testing.

unlike everybody else in this comment section, i like the two-mode toggle. but that's just my opinion. without user testing numbers, an article saying "users like this better" is useless.

But...there is a solution that works (although it may be a bit confusing at first). A toggle with two buttons, dark and light. Both cannot be pressed at the same time, but both can be unpressed at the same time. That's the auto mode, and the ui can be tweaked to show a little label in between or below.

In auto, none of the buttons is pressed (and preferable a small label that says auto is shown). Pressing dark/light will force that mode, enable that button and remove the auto label.

In dark/light mode, you can press the other button to enable the other state. Or you can press the current button to disable it, and switch to auto. This last one is the confusing-at-first interaction, but makes sense if you think about it (it's like saying: I want dark / I want light / I don't care)

New requirement just dropped: "Switch to light mode during more than 50% solar eclipse".