# New York Times How we design and build digital products at The New York Times. - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Building the Crossplay Board DevFeed: [Building the Crossplay Board]() Original publisher: [Read original article]() Author: The NYT Open Team Published: 2026-06-08T16:46:30Z Content type: tutorial Language: en Sources: [New York Times]() Topics: [Android](), [Development](), [Jetpack Compose](), [Mobile](), [ui](), [screen](), [real-time]() Tags: [android](), [android-app-development](), [asynchronous](), [code](), [compose](), [development](), [draggable](), [jetpack-compose](), [kotlin](), [mobile](), [multiplayer](), [real-time](), [screen]() ### AI overview The New York Times Games team describes building the Android game board for Crossplay, a multiplayer word game with a 15x15 grid, draggable tiles, real-time animation, and asynchronous matches. The team used a hybrid architecture: an Android GridLayout with 225 tile Views integrated into surrounding Jetpack Compose UI. ### Source excerpt How We Made a 15X15 Game Surface Feel at Home on AndriodIllustration by Lehel Kovács By Shafik Quoraishee What Is Crossplay? The New York Times Games team has been building daily puzzles for quite a while: Wordle, Spelling Bee, Connections, The Mini. These are solo games. The player opens them, solves them, and then closes them. This leads to a simple, satisfying experience which delights millions of players a day. Crossplay is an altogether different endeavor. It's the first multiplayer game from NYT Games, and it brings a friend (or a stranger) into the experience with them. So two players, one board, in real time. In Crossplay, players take turns placing letter tiles on a 15x15 grid to form interlocking words, but built for mobile with a focus on speed, fairness, and the back-and-forth tension that compels the player to play one more round. The matches are asynchronous by default. The player makes their move, the opponent gets notified and responds when they're ready. But the board animates as if the players are both sitting at the same table. When we set out to build it, we knew the board would be the hardest part. While the networking, the opponent matching, and the game logic were all challenging work, the board itself which is part of the core game loop was the most difficult piece because of the number of interactions required to make it function correctly, in concert. Since every cell is a potential drop target and every tile is draggable, the board needs to respond instantly to touch *and* animate their opponent's moves *as they happen*. This all must occur on a screen that is a few inches wide. In this post we discuss what it took to get that right on Android. Starting with the Grid One of our first questions was architectural. How should 225 tiles be laid out? Jetpack Compose is the obvious modern choice. But Crossplay's development started before our team had fully migrated to Compose, and the game board had specific requirements that made a pure-Compos ## How The New York Times Games Team Delivered Accessible, Cross-Platform Dark Mode DevFeed: [How The New York Times Games Team Delivered Accessible, Cross-Platform Dark Mode]() Original publisher: [Read original article]() Author: The NYT Open Team Published: 2026-04-16T15:35:45Z Content type: article Language: en Sources: [New York Times]() Topics: [Dark Mode](), [Mobile](), [Android](), [iOS](), [Jetpack Compose](), [ui](), [Design system](), [XML](), [pull-requests](), [SwiftUI](), [Objective-C]() Tags: [accessible](), [android](), [collaboration](), [cross-platform](), [dark-mode](), [design](), [design-system](), [engineering](), [ios](), [jetpack-compose](), [pull-requests](), [swiftui]() ### AI overview The New York Times Games team describes implementing accessible, brand-consistent dark mode across its mobile app. The work coordinated design and engineering across Android and iOS, including XML and Jetpack Compose screens, legacy and modern interfaces, shared assets, external libraries, and testing. ### Source excerpt Bringing accessible, brand-consistent dark mode to life in The New York Times Games app through cross-platform design and engineering collaboration.Illustration by Allie Sullberg By Vanessa Johnson, Daniel Falokun, Michael Ingber and Oleksandr Zabiiako The Games Mobile App introduced dark mode back in October. This seamless implementation was a collaborative effort, requiring careful planning and management of design, cross-platform coordination, and engineering work across both legacy and modern user interface systems. The process to implement dark mode across the app included consideration on the visuals, colors, and icons that are mode specific to maintain legibility and brand consistency. The New York Times Games team is excited to have delivered this feature before the end of 2025, and thrilled to be able to roll out a feature that continues to make our app accessible for all. Development Work on Mobile On the development side, the mobile and web engineers synchronized assets which were colors, fonts, and images to ensure that hybrid screens showed the correct styles and colors. This was possible since our design system across mobile was constructed in a way that encouraged consistency and scalability across platforms. With clear and easy to follow designs supported by our internal design system, Android and iOS could ensure consistency on both platforms. Screens in dark mode From an Android perspective, it required separate approaches for XML (Extensive Markup Language) based screens which use an imperative, hierarchical approach and Jetpack Compose screens that use a more modern declarative approach. XML and Jetpack Compose are different ways the UI can be constructed. To ensure dark mode compatibility, all features were revisited to make sure they were adapted, especially the additions that were being worked on during the dark mode project. Another aspect of this development was updating external libraries that required making pull requests, creating a versi ## The Right Team for the Job: From Engineering to Product: A Superpower for Developer Platform... DevFeed: [The Right Team for the Job: From Engineering to Product: A Superpower for Developer Platform...]() Original publisher: [Read original article]() Author: The NYT Open Team Published: 2026-02-11T21:52:17Z Content type: article Language: en Sources: [New York Times]() Topics: [Developer Platform](), [code productivity](), [Software Engineering](), [systems](), [Back end](), [Content Management System](), [Product Management]() Tags: [backend](), [cms](), [developer](), [developer-platform](), [developer-productivity](), [development](), [engineering](), [product](), [product-management](), [software-engineer](), [web-development]() ### AI overview This New York Times Open series article introduces Danny Cassidy, a senior technical product manager in Developer Productivity, and traces his transition from software engineering to product management. It describes his early frontend work, later experience building backend APIs and content management systems, and his interest in connecting engineering decisions with business and user impact. ### Source excerpt The Right Team for the Job: From Engineering to Product: A Superpower for Developer Platform StrategyIntroducing Danny Cassidy, Senior Technical Product Manager, Developer Productivity in Developer PlatformsIllustration by Claire Merchlinsky By Geethu Jacob, Daniel Cassidy, Nikki Larson and Erica Vendetti "PMs actively and effectively engage with engineering and technology decisions, understanding possibilities and consequences." This article is part of a New York Times Open series showcasing the breadth of experiences and backgrounds of our Product Managers. Engineering can fuel product leadership For Danny Cassidy, coding was an early creative outlet. As a high school student, he taught himself to code, trying his hand at frontend web development. "I was very inspired by online communities back then, and how the internet could foster connection for people across the world. So, I first learned how to make extensions on forum software. My first paid gig in high school was building a social networking feature into a site for pet owners so that they could create profile pages for their pets. Those were the days!" Building on the base of that passion, Danny studied information technology in college. "There's a definite craft to software development", he says. "It's not just technical. You are thinking about solving a problem in an elegant and legible way. I always enjoyed that part of the process." As a software engineer, Danny focused on building backend APIs and content management systems (CMS) for media brands. Here, Danny learned to understand how engineering solutions fit into the business context. Engineers "need to know how a solution will evolve and scale over time. And their solutions need to be understood and maintainable by a multitude of people throughout all of this." In 2015, Danny accepted an engineering job at The Times working on the backend APIs that deliver our digital content from our CMS to our desktop and mobile apps. As an engineer at The New Yor ## Building The New York Times Product Team: The Right Team for the Job DevFeed: [Building The New York Times Product Team: The Right Team for the Job]() Original publisher: [Read original article]() Author: The NYT Open Team Published: 2026-02-11T21:42:32Z Content type: opinion Language: en Sources: [New York Times]() Topics: [Product Management](), [Users](), [Artificial Intelligence]() Tags: [ai](), [leadership](), [mission](), [product](), [product-management](), [skills](), [teams](), [users]() ### AI overview The article introduces The New York Times product team, describing how product managers with varied professional backgrounds use product strategy, analytical rigor, communication, leadership, and execution skills to address reader, business, and organizational needs. ### Source excerpt Illustration by Giacomo Bagnara By Nikki Larson, Erica Vendetti and Michael Beach Our mission is simple: We seek the truth and help people understand the world. Accomplishing that mission requires each of us to build trust, seek out different perspectives, collaborate respectfully, and continuously strive to deliver the very best in all we do. But what exactly does that mean for Product Managers (PMs)? How do we earn and maintain trust with tens of millions of global readers in an era of misinformation? Where are new readers finding and developing a daily habit with our original reporting? How can Product unlock growth opportunities for our business? How can we help readers connect with their passions by building products like Games, The Athletic or Cooking? How do we use AI to responsibly advance our mission? How do we scale our systems to support breaking news? PMs at The New York Times solve a variety of problems for our readers, our journalists, other product and functional teams. To meet the evolving needs of our almost 12 million subscribers, we rely on a Product team with a wide range of unique backgrounds. It takes creativity and expertise from people in every part of the company to fulfil our mission. So it's not uncommon for our PMs to have started their careers in roles outside of product. To build a world-class Product team, we've hired both PMs by trade as well as those who were previously dancers, consultants, entrepreneurs, journalists, strategists, operations specialists, and engineers. Our diverse experiences fuel the analytical rigor, creativity, communication skills, leadership, and execution skills needed to excel in getting to know our users' needs and leading teams to build solutions to meet them. This post will help introduce you to PMs whose backgrounds outside of Product Management help them excel in their current roles at The New York Times. One guiding framework, many possible solutions While our PMs work on products across the entire busi ## How The New York Times is scaling Unit Test Coverage using AI Tools DevFeed: [How The New York Times is scaling Unit Test Coverage using AI Tools]() Original publisher: [Read original article]() Author: The NYT Open Team Published: 2026-01-13T18:51:55Z Content type: article Language: en Sources: [New York Times]() Topics: [Artificial Intelligence](), [test-coverage](), [unit test](), [Testing](), [Development](), [Web app](), [React]() Tags: [ai](), [ai-tools](), [code](), [coverage](), [development](), [reliability](), [scaling](), [software](), [test-coverage](), [testing](), [unit-test](), [unit-testing]() ### AI overview The New York Times describes using AI tools to expand unit-test coverage across its News site. The agents improved efficiency and coverage on critical code, but required strict human supervision and human review of the generated tests. ### Source excerpt How AI tools are helping our software engineers write better tests at scaleIllustration by Nick Little By Eric Chima and Leonardo Quixadá At The New York Times, we're all excited to build fresh new experiences that delight our users. Our product managers are driven to find new ways to get our work in front of our audience and build reader engagement. Our engineers are motivated to solve unique technical challenges. And just when you think all that work is on track, breaking news strikes and all of our plans change at once. With all that going on, who could blame us if our test coverage couldn't quite keep up? Like every engineering organization, The Times deals with routine maintenance tasks: updating dependencies, cleaning up old code, maintaining accessibility standards, and, yes, building testing into all of our products. Our engineers are committed to quality, but when you work at the speed of news, there's always a new issue that needs to be addressed. Fortunately, generative AI has arrived with the promise of tidying up after us, taking care of the busy work, and giving time back to our developers to focus on feature development. But how far can you trust it? Recently, one of our platform teams used AI tools to build out unit tests across our flagship product, the News site. This was an opportunity for our testing to catch up with our rapid development. Our goal was to improve the reliability of our web app, but also to evaluate AI products and determine how far we could push them to do work in bulk across our codebase. As expected, the agents required strict human supervision, but they improved our efficiency in writing tests and let us quickly expand coverage on some of our most critical code. AI accelerates, but humans test the tests Unit tests are a crucial part of the development process. The idea is to divide application code into small pieces and write tests for each, creating guardrails to ensure that changing one piece of the site doesn't impact the r ## Designing a Digital New York Times Museum DevFeed: [Designing a Digital New York Times Museum]() Original publisher: [Read original article]() Author: The NYT Open Team Published: 2025-10-15T18:30:40Z Content type: article Language: en Sources: [New York Times]() Topics: [digital](), [Requirements](), [navigation]() Tags: [archive](), [design](), [employees](), [intern](), [navigation](), [product](), [product-design](), [remote](), [requirements](), [sessions]() ### AI overview Five product design interns describe designing a proof-of-concept virtual museum that brings The New York Times' internal museum to remote employees. The article covers their research, requirements, user flows, navigation, onboarding, and artifact-page design. ### Source excerpt How five product design interns created an award-winning virtual museum experience for employeesIllustration by Lucas Burtin By Nuoran Chen, Mina Chung, Frannie Ello, Christina Su, and Bella Rinne A key element of The New York Times Product Design Internship Program is a cohort project where all the interns work as a group to create a deliverable that is presented to the entire product design team. We, the summer 2024 cohort, were tasked with designing a proof-of-concept that brings the internal company museum in the NYC office to remote employees. The Times Museum is home to multiple artifacts where visitors can freely roam from each display to understand how their stories intertwine. From an official letter authorizing the publication of the leaked Pentagon Papers to physical effects of our war correspondents, each display is unique and speaks to the history behind The Times' mission to bring independent journalism to all. Our group began our work with a tour of The Times Museum led by retired journalist and museum curator, David W. Dunlap. On this tour, David guided us through each artifact in chronological order, describing the stories behind each piece and additional facts that were not fully captured with labels. His guided tour was essential for understanding the details behind The New York Times history and journalistic evolution. This tour informed two key requirements for the virtual museum. A guided tour with pathways for autonomous exploration: Visitors should experience the museum in order as it was curated while also being able to explore independently. Highlight important artifacts: We want to reduce the cognitive load for visitors and prominent artifacts so visitors are not overwhelmed when they enter the virtual museum. With these defined requirements, we began the design process. We held multiple brainstorming sessions to prioritize features and propose user flows in this virtual museum, but quickly found ourselves at a roadblock. For many weeks, w ## Scaling Subscriptions at The New York Times with Real-Time Causal Machine Learning DevFeed: [Scaling Subscriptions at The New York Times with Real-Time Causal Machine Learning]() Original publisher: [Read original article]() Author: Rohit Supekar Published: 2025-10-03T15:19:24Z Content type: article Language: en Sources: [New York Times]() Topics: [Machine Learning & Artificial Intelligence](), [Algorithms](), [Optimization](), [real-time]() Tags: [account](), [algorithms](), [causal-inference](), [causal-machine-learning](), [data](), [data-science](), [machine-learning](), [optimization](), [users]() ### AI overview The New York Times describes replacing its Dynamic Meter machine-learning model with real-time algorithms that decide within milliseconds whether users receive access. The system uses causal machine learning and multi-objective optimization to balance subscription, registration, engagement, conversion, and business constraints across its subscription funnel. ### Source excerpt How real-time algorithms and causal ML transformed our digital subscription funnel from static paywalls to dynamic, millisecond decision-makingIllustration by Mathieu Labrecque The New York Times became a subscription-first news and lifestyle service with the launch of its paywall in 2011. Since then, our subscription strategy has evolved substantially. Initially, users could access a limited number of free articles per month before they encountered the paywall. In 2019, we began personalizing this number using a Machine Learning (ML) model -- The Dynamic Meter. In the past few years, we have replaced this model with real-time algorithms that decide, typically within milliseconds, whether to grant access. These algorithms are tailored to balance and optimize the tradeoff between several business Key Performance Indicators (KPIs), while also allowing us the flexibility to adjust for any business constraints. This article further details the motivation behind these algorithms and their design based upon principles from causal machine learning and multi-objective optimization. Our subscription funnel The New York Times has a tiered subscription funnel (Figure 1), consisting of unregistered, registered, and subscribed users. This funnel is designed to provide non-subscribers with limited access to our content, allowing them to discover our offerings. At other times, the content may be blocked by a digital "wall". We have two types of walls -- a registration wall that asks a user to register for a free account or log in, and a paywall that asks a user to subscribe. A large number of users are unregistered -- they may be shown either a registration wall or a paywall. Once a user is in the registered state, they can be shown only a paywall. Figure 1: The New York Times subscription funnelOptimizing the subscription funnel Optimizing who sees the registration wall or the paywall -- and when -- is a very relevant question for our business. While blocking access encourages users t ## The New York Times Games' Path to Dark Mode DevFeed: [The New York Times Games' Path to Dark Mode]() Original publisher: [Read original article]() Author: The NYT Open Team Published: 2025-09-25T15:25:52Z Content type: tutorial Language: en Sources: [New York Times]() Topics: [Dark Mode](), [Design system](), [Accessibility](), [User Experience](), [Web Development]() Tags: [accessibility](), [dark-mode](), [design](), [design-systems](), [development](), [front-end-development](), [games](), [user-experience]() ### AI overview The New York Times Games explains why implementing Dark Mode required more than inverting colors. The project involved accessibility decisions, preserving each game's brand, and creating a consistent design system across eight games and three surfaces. ### Source excerpt How we designed a deceptively complex featureIllustration 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. A compilation of negative Games app reviews that reference dark modePrimer: 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 e ## Using Provocations to Shake the Status Quo DevFeed: [Using Provocations to Shake the Status Quo]() Original publisher: [Read original article]() Author: The NYT Open Team Published: 2025-07-22T16:23:11Z Content type: opinion Language: en Sources: [New York Times]() Topics: [Users](), [format](), [context]() Tags: [approach](), [design](), [engineering](), [figma](), [photography](), [process](), [recipe](), [ux-design](), [visual-hierarchy](), [visualization]() ### AI overview A case study of how NYT Cooking used high-fidelity design provocations to rethink recipe cards. The approach prioritized photography, flexible recipe information, a modernized format, and a more streamlined evaluation process while keeping the project scope controlled. ### Source excerpt The bold approach NYT Cooking used to define a strategy for recipe cards.Illustration by Ben Denzer By Jayne Lee In The New York Times Cooking, "cards," or the containers that represent our content, are the first impression of our brand. They're the window into our recipes and users rely on them to evaluate and choose what to cook. NYT Cooking users are particularly attracted to our appetizing food photos. In every research session, participants get distracted by a delicious-looking dish while answering the moderator's questions. People tend to browse with their stomachs first and then see if the recipe specifications meet their personal criteria (For example, do I have enough time to cook this?). A problem we encountered: our beautiful photography was muddied by the page's gray background. The white card containers sitting on top of the gray page forced your eyes to focus on the container instead of the photo. The visual hierarchy was at odds with the preferred reading and browsing order of our audience: photo first, then recipe information. Recipe information varies, so the card needs to afford that variability. Using containers forced us to keep our cards the same height, resulting in unnecessary whitespace. Since the cards were so tall, this limited the amount of recipes a user could see at once, increasing the time users scanned for recipes. We needed to highlight our photography, modernize the format and streamline the recipe evaluation process. While designing solutions, I realized that I had more questions than answers. Answering each question would have significantly bloated the project scope. Some examples were: What order of recipe information is most helpful when deciding between recipes? Are recipe bylines important? Which presentation of ratings is more effective? Because the priority was to update the format rather than improve comprehension, and to avoid bloating the scope of the project, I started with design provocations over design specs. Because ## Developing an Internal Tool for Our Puzzle Editor DevFeed: [Developing an Internal Tool for Our Puzzle Editor]() Original publisher: [Read original article]() Author: The NYT Open Team Published: 2025-06-02T15:54:44Z Content type: article Language: en Sources: [New York Times]() Topics: [dashboards](), [Data Management](), [interface](), [payload](), [Testing](), [Tool]() Tags: [code](), [dashboard](), [data-management](), [developing](), [interface](), [internal-tools](), [payload](), [puzzle](), [testing](), [tool](), [web-development](), [workflow]() ### AI overview The article describes how The New York Times developed the Connections Reference Dashboard, an internal tool for managing puzzle data and supporting the Connections editor's workflow. It explains the tool's interface, handling of changing puzzle data, search capabilities, and reduction of manual cross-referencing steps. ### Source excerpt How we developed a dashboard tool created to help ease the workflow of managing puzzles for our Connections editor.Illustration by Su Yun Song By Shafik Quoraishee and Wyna Liu In the game Connections, every puzzle is a meticulously crafted challenge designed to captivate our audience and spark intellectual curiosity. Developing these puzzles can sometimes be a time consuming and intricate task. Each puzzle requires planning, beginning with conceptualizing fresh categories and plausible misleads, followed by testing the combinations for balance and solvability, and concluding with refinement and publication-ready formatting. The process requires both creativity and quality control. Wyna Liu, the editor of Connections has the responsibility of constructing and reviewing multiple puzzles spanning various dates, ensuring that each board remains consistent, fresh and challenging to our puzzle solvers. This is a challenging endeavor where there isn't much room for error. In order to address the challenge, we developed the Connections Reference Dashboard -- an in company tool aimed at streamlining data management while providing the puzzle editor with an intuitive, aesthetically pleasing interface that enhances the daily workflow. There were two considerations in developing this tool. Firstly was technical work in handling a dynamically changing payload of puzzle data. We wanted to create a rich and visually resonating interface that was easy to navigate and gave a bit of the feel of the Connections game itself. Therefore, everything from the board results to the search interface was designed with these ergonomics in mind. We wanted to create a level of tactility to the tool which was reminiscent of and which reduced the number of manual steps needed to cross reference both categories and words in individual boards. The primary functionality that Wyna was after was the ability to quickly identify words that have appeared in previous Connections boards, as well as their con