When I first approached this project, I assumed dark mode would be a relatively simple lift — flip the colors, invert the backgrounds, and call it a day. But once I started digging deeper, I realized how much strategy was required to create something that wasn’t just functional, but intentional. There wasn’t always a one-to-one solution, and that forced me to look beyond the color values themselves and focus on context — how colors function at the component level, not just where they appear.

The biggest lesson? Accessibility isn’t about doing what seems right — it’s about making decisions that are right, even when they aren’t straightforward. Inverting a color may give you its technical opposite, but not necessarily a usable or legible alternative in dark mode. That nuance pushed me to break from the “expected” and instead build a framework that prioritized contrast, readability, and meaning. Our final output wasn’t just a color update — it was a full documentation system that outlined when, where, and why certain tokens should apply based on component states and locations.

Looking back, I’m proud of how much ownership I took in shaping the logic of this system. If I could approach the next iteration differently, I’d love to bring in real-time user testing for visual comfort — especially for edge cases like colorblind modes or motion sensitivity. Since much of this work was behind the scenes, future rounds could benefit from observing how users actually respond to the visual changes, not just how they perform technically. That added layer would make the system even more inclusive and durable in the long term.