> Providing the users of a product with the option of a Dark Mode is a good business decision, especially if the application requires users to spend lots of tim

> Providing the users of a product with the option of a Dark Mode is a good business decision, especially if the application requires users to spend lots of time on the application. I just got done correcting ten exception requests, and this kind of blithe assurance is why I empathize with the compliance guy who insisted we had to explain why we needed these, in particular, how not approving them would impact our business. They provide a pretty reasonable example of where a dark mode makes sense: a streaming service where people are likely to be in a dark room watching mostly your video. It is not self-evident that adding an option for dark mode is a good business decision in general, though. Let me present a counter example: when I receive a package in Amazon Hub, I recieve an SMS (but it's really an MMS) with a six-digit code and a barcode image. The Hub lockers have a barcode scanner and a keypad. I have gotten the barcode to scan a few times, but it almost always fails and I just punch in the code. The Pixel is usually in dark mode when I scan. It has worked in light mode. I'm not inclined to hang around the package locker for ages messing with it, though. Granted, this is already stupidly broken, but the dark mode option introduces additional uncertainty as to whether it's the cause of this seemingly unrelated process being broken. Is framing the barcode in black going to interfere with a scanner? Maybe? Before you claim that it's a good business decision, you need to at least confirm it's a net benefit to users: 1. if it's an option, do they find the option? How does it interact with the system option if any? Is it consistent between platforms? 2. if users toggle the option and a year later want to toggle it again, do they find it again? Or do they complain to support? Or do they delete the application in frustration? 3. are you going to properly test two sets of UX? 4. did you test uncommon cases, e.g. toggling it while the application is running? 5. looking back to my example, will it interfere or appear to possibly interfere with unexpected use cases? Then your business case is tangible benefits (greater sales) + intangible benefits (trust, reputation, delight) - tangible costs (testing, design, support) - intangible costs (confusion, frustration). If it's a core use case, e.g. streaming video, or if you can do it simply, especially via the native widgets, then it's likely a good business decision. Otherwise, it gets dicey.