Brightness Test

The brightness test is a hands on dark mode QA ritual that drops your entire interface to 30 percent screen brightness in a pitch black room. It forces every surface, border, text token, and accent color to prove it works under the exact lighting conditions users encounter at night. This is where the theoretical rules from the dark mode paper meet reality. Pure black backgrounds reveal themselves as depth killers. Subtle shadows that worked in light mode disappear. Elevation systems built on lightness steps either hold their hierarchy or collapse into a flat mess. The test catches halation from text that is too close to pure white. It reveals when disabled buttons have blended into their surfaces. It shows exactly which focus rings lose their visibility and which brand accents have not been desaturated enough for the dark environment. Top teams treat it as mandatory because dark mode is not an aesthetic choice. It is a battery saving accessibility feature that users now expect as table stakes in 2026. The brightness test is the only reliable way to confirm that your second theme earns its place instead of feeling like an afterthought inversion.

It is not a software tool or automated script. It is not another row in your contrast audit spreadsheet. It is not something a junior designer can run in a sunny office while drinking coffee. Those approaches miss the point. Contrast checkers tell you that #D4D4D8 on #17171C clears 4.5 to 1. The brightness test at 25 percent brightness tells you that the same combination creates eye straining glow around 13px body text after 45 minutes of use. Automated visual regression cannot detect that your menu items have lost all separation or that your illustrations have turned into invisible ghosts. The test requires you to sit in the dark and actually use the product. It is subjective by nature yet repeatable enough to drive token changes. It is the perceptual companion to the mathematical checks. One without the other leaves half the problems unaddressed.

A concrete example is the 2025 dashboard update from Linear. The team followed the dark mode paper to the letter. They built semantic tokens with separate maps for each theme. They avoided pure black and pure white. They created a five step elevation scale starting at #0E0E13 for base and stepping up to #2F2F38 for popovers. Yet when they ran the brightness test in a darkened room at 30 percent the results were sobering. The border token they chose for subtle dividers at #25252C disappeared against raised cards. Their primary accent at full saturation felt aggressive and eye grabbing in a bad way against the elevation 2 surface. The disabled button states at 30 percent opacity blended too much with their background. The team made targeted fixes. They updated color.border.default in the dark theme map to #35353E. They desaturated their brand blue from 100 percent to 82 percent and lightened it two stops. They changed disabled opacity to 45 percent on top of the surface color. A second round of the brightness test at 22 percent confirmed the issues were resolved. The final dark mode shipped to widespread praise for feeling intentional and comfortable for long coding sessions. The light theme remained completely unaffected thanks to the token architecture.

Another concrete example comes from Figma's 2024 dark mode expansion to their entire plugin ecosystem. Early versions passed internal reviews but failed the brightness test when applied to complex community plugins with heavy illustration use. The test revealed that white stroke illustrations vanished completely against the new surfaces. Image heavy template previews looked broken without dedicated dark assets or background containers. Focus states on tiny plugin controls became invisible at low brightness. The Figma team responded by creating a dedicated dark mode illustration set for key assets and adding the recommended soft light background treatment to every image frame in dark mode. They also increased their focus visible ring brightness by 15 percent for small elements. These changes were all driven by repeated brightness tests across multiple devices including iPhones where OLED black levels made certain grays read completely differently than on studio displays. The result was a cohesive experience that reinforced rather than fractured their brand.

Use the brightness test when your semantic tokens are fully mapped and every component has its dark variant defined. Run it on every key screen and new component in a pitch black environment at 30 percent brightness or lower. Perform it on both laptop and mobile devices since OLED and LCD screens expose different issues. Always pair it with a full contrast audit and screenshot comparisons. Make it a permanent part of your design system release checklist so new additions cannot break the theme. It is especially valuable for data dense interfaces, developer tools, design applications, and any product that sees heavy use after dark. Do not use it during early ideation when judging hue and mood or if your foundation still relies on messy CSS overrides instead of proper theme maps. The test will only highlight problems that cannot be fixed without first correcting the token structure. Avoid it in lit rooms or at high brightness settings because the simulation fails. Never treat it as a full replacement for user testing with people who have photophobia or for strict WCAG audits using tools like axe.

Run the brightness test religiously or watch your carefully crafted dark theme slowly turn into the harsh inverted mess you swore you would never ship.