The New York Times Games' Path to Dark Mode

Press enter or click to view image in full size

Illustration by Alessandro Gottardo

By Joel Urena, Jenna Kim, Kenneth Ofosu, Shaka Clark, Raven Adaramola, Dylan Campbell

At least once a day, our players requested a Dark Mode feature for The New York Times Games, particularly those who enjoy playing at night. The bright screens were negatively impacting their satisfaction and hindering accessibility. Our players often wondered why this seemingly simple feature — just a switch from white to black — took so long to deliver.

People may think designing for Dark Mode is about inverting colors from white to black, one of the points players often cited when asking for Dark Mode. But there are numerous factors that make up little decisions when designing and implementing Dark Mode. Not only do we have to consider the color accessibility, we have to make intentional color decisions to preserve the brand of each game and The New York Times Games.

Press enter or click to view image in full size

A compilation of negative Games app reviews that reference dark mode

Primer: Design Systems & Feature Discovery

In the Spring of 2023, The New York Times Games was evolving quickly and we found ourselves with a user experience that was vastly different depending on which game you played and where you played it. We began to rectify this problem with the development of a Design Systems strategy. Like most other tech orgs, we hypothesized that if we began approaching product design and front-end development systematically, surely that would orient us toward a more consistent product experience, right? The answer: yes, eventually.

From a business and user impact perspective, the clearest Design Systems opportunity to prioritize first was Dark Mode. However, given the maturity of The New York Times Games digital product, the operational complexity we were tackling was massive. At the time, we had eight live games spread across three surfaces: The New York Times Games apps, the The New York Times news app and on the web. We also had ancillary experience for some of these games in the form of our companion articles (e.g: Spelling Bee Forum, Daily Crossword’s Wordplay column).

What we thought would be a simple color switch became an extensive exercise in paying down years of design debt. We discovered that each game had its own distinct user experience, with different fonts, color palettes, and component styles. Implementing a consistent Dark Mode across everything meant we couldn’t just add a new theme; we had to audit every screen and standardize the design from the ground up. This complexity forced us to make a critical decision: should we spend years paying down this debt, or could we find a way to scope Dark Mode in a way that delivered immediate value to our players? Our solution was to prioritize the user-facing experience over a complete systemic overhaul, giving us a path to delivery while continuing to chip away at the underlying issues.

We made the strategic choice to restrict Dark Mode to the Games app, which allowed us to narrow our technical and design focus to typical mobile and tablet display sizes. This decision also served to distinguish the Games app experience from our other platforms, aligning with our long-standing objective of establishing it as the premier destination for playing our games.

We then began unpacking the remaining scope. Product managers developed a visual to help cross-functional teams get a sense of what work needed to be done to get us to ship our first Dark Mode experience.

Press enter or click to view image in full size

Path to Dark Mode In Apps

Once we understood the work ahead, our next step was to pitch the project to Games leadership for a spot on the roadmap. We publish our games using a hybrid strategy — our apps are a native shell built around our web-based games — which meant we needed to align our web and app teams. Given the competing priorities we faced on the Games App roadmap, this was a hard sell. We ultimately struck a balance between the two teams by aligning on a UX that leveraged our hybrid model to give users the maximum amount of flexibility when determining their theme preferences. Just like with Wordle, every game would have its own Dark Mode setting.

Designing the System

Now that it was approved, we wondered, “what are steps to actually get to Dark Mode on Games? How does engineering come into play as designers are exploring?” We decided to create a strategic chart outlining the high-level steps to the feature: Alignment, Foundation, Exploration, Integration. There were still unanswered questions, such as whether to launch all the Dark Mode features at once or to keep the scope narrow by launching it for each game individually. Creating this outline of the design strategy helped us gain clarity that we need to launch Dark Mode individually, reducing the complexity of the project by breaking things down, a common pitfall when working on design systems. This approach also mitigated risk as it allowed us to go through visual quality assurance for each game.

Press enter or click to view image in full size

Product strategy diagram

Press enter or click to view image in full size

To ensure Alignment, we presented to the wider team on the importance of investing in design tokens. Because the wider team was so accustomed to using hex values for colors, it was crucial to change the way designers and engineers work with color.

For Foundation work, we conducted an audit of all game surfaces to identify any misalignments or discoveries. The New York Times Games product expanded significantly from its initial focus on The New York Times Crossword to include over eight distinct games. This growth, however, occurred without a unified design system. Consequently, each game surface utilized unique hex values, even when visual similarities were present.This investigation again proved the importance of design systems. To address this problem, the hex values used within our products were assembled into primitive/base tokens which will later be used to create semantic tokens which are more complex, intricate tokens used for more specific use cases. Also, thinking about how to help other designers discover the color they want efficiently in the future and understanding the complexity of our surfaces, we made a decision to establish three separate color component libraries with semantic libraries: Games Home Surfaces, Games Brand, Gameplay Color libraries.

• Games Home colors are general, foundational colors primarily used for utilitarian purposes for text, background, and stroke.
• Game Brand colors consist of design tokens used for brand purposes, such as Spelling Bee Yellow, Connections Purple, The Mini Blue, etc.
• Gameplay Color tokens are color tokens used for gameboards and game interactions.

Press enter or click to view image in full size

When the time came for diving into Exploration, we approached each game as a separate project. We held each other accountable by reviewing each others’ design tokens. We discussed and consulted with one another on names for alignment — beginning the development of a ‘shared language’ for the system that we could leverage cross-functionally. We put strong emphasis on playability in gameplay through multiple rounds of prototypes to make sure the game experience of a light mode feels the same as the dark mode. For example, tiles within Connections have a very distinct beige color and do pass the accessibility test on a dark black background. However, it can feel overly bright on a dark background, so we adjusted the saturation of the beige to have a consistent game experience.

Press enter or click to view image in full size

As we were getting close to handing off the designs to engineers, we also implemented a way for users to switch preferences within Settings since not all users prefer to have Dark Mode at night or they would prefer to have only certain games in Dark Mode. We wanted to deliver a flexible game experience where users can have a choice and be in control of what mode they want for each game.

Putting the Pieces Together

Our design system was engineered with the primary goal of ensuring consistency and scalability across both our internal and external products, beginning with our games. By providing a unified set of design tokens and reusable components, it bridges the gap between design and development, enabling our team to deliver a cohesive user experience. While still in development, the system is already proven to be a valuable tool for maintaining visual and functional consistency across our products. Collaboration has been at the heart of this effort, with several members of our engineering, product, and design functions working closely to align on requirements, standards and best practices.

The design system is built using React with CSS modules for styling, and it is documented in Storybook to ensure ease of use for all stakeholders. We leverage TypeScript for type safety, Vite as a build tool for fast and efficient development, and Playwright for visual regression testing to maintain quality. Design tokens, such as spacing, colors (used to implement dark mode) and typography are implemented using CSS variables to ensure scalability and flexibility. To enforce code quality and consistency, we use Stylelint and ESLint, integrated with Git hooks via tools like lint-staged and husky. These tools ensure that every contribution adheres to our standards, making the system reliable and maintainable. We then created a React Provider and utilized React hooks, which enabled us to roll out the new palette per game and per surface, to ensure we did not have to add the new feature to all surfaces and games at once. Overall our implementation strategy worked, allowing us to incrementally add color tokens without users noticing the difference. Many of the challenges we faced in the project related to our previous css and styles decisions in our code base.

One of the most rewarding aspects of building the design system has been the collaborative process. Weekly and ad-hoc meetings with engineers, engineering managers, product managers, and designers allowed us to align on requirements, share knowledge, and roadmap future improvements. This has fostered a shared sense of ownership and ensured that the system meets the needs of all users. Looking ahead, our vision is for the design system to become the single source of truth for all design-related information, encompassing both design tokens and shared components. By continuing to iterate and expand, we aim to make the system an indispensable resource for our team and a foundation for scalable, high-quality product development.

Takeaways

Building Dark Mode for The New York Times Games revealed two significant wins. First, what started as a focused effort to improve workflow through design systems evolved into a powerful tool for consistency and scalability across our products. We’re now extending this foundational work to other elements like fonts, spacing, buttons and shared patterns.

Second, the data clearly shows the positive impact of Dark Mode on our players. Users who engage with Dark Mode exhibit higher engagement, playing and completing more puzzles. Our strategic decision to prioritize the user-facing experience allowed us to deliver immediate value while systematically addressing underlying design debt.

Our efforts have delivered a feature that directly addresses our players’ long-standing desire for a more comfortable nighttime solving experience, allowing them to enjoy their favorite puzzles well into the evening.

Press enter or click to view image in full size

Special thanks to:

Jennifer Scheerer & Jessica Gerson for design support and leadership. Michael Beach & Blake Spikestein for product support and leadership. William Frohn for motion design. Ian Hipschman, Ashby Thornwell, Lauren Yew, Goran Svorcan, Ihor Shamin, Katie Leavitt and the entire Games App Squad for their partnership. Emily Ngo for the Data Insights and Experimentation Support. Nick Ritenour, Coryn Brown and The New York Times Marketing team for their partnership