How The New York Times designed a planning tool as part of their CMS to help streamline newsroom workflow.
The New York Times print paper is sometimes referred to as ‘The Daily Miracle’ for the astounding amount of coordination and labor it takes to produce. The miracle isn’t confined to the printed paper, however. It includes the numerous people who work on a single story, readying it for publication. It involves the planning of publication dates and promotion strategies for the more than 200 original pieces of journalism that are published daily — only some of which end up in the printed paper. It’s the production of our homepage and our apps, and the curation of our presence on social media.
The amount of coordination across all of these fronts is nothing short of miraculous, but with so many moving parts, collaboration and cross-desk transparency can be difficult.
Over the years, editors developed their own methods for documentation and often created complicated planning flows that involved an ever-evolving combination of platforms and tools. In addition to being chaotic, this sometimes resulted in duplicated administrative work, data inconsistencies and siloed knowledge; sometimes it meant great stories weren’t properly promoted. We needed a solution that would improve our newsroom workflow.
Before we started, we had two main questions:
- How can we create a system that makes coordination across dozens of desks, each with their own needs and workflows, simple and flexible?
- How can we help platform and off-platform editors program content on our home page and social media accounts?
Our initial answer: we didn’t know!
But we did know we needed a tool that made print and digital production transparent, where all types of editors could easily find the articles they’re working on and collaborate. We also knew we needed a unified system for editors to plan and publish their daily report, because better tools and simpler planning workflows lead to a better experience for readers.
After evaluating third-party solutions and comparative products used by competitors, we didn’t find a silver bullet that would work for our newsroom workflow. So project leads Johna Paolino and Kellen Henry worked with Tessa Taylor, Dylan Nelson and me on the engineering side and we experimented.
Working with editors from the Business, Climate and Science desks, as well as editors in charge of platform and off-platform programming, we designed and built a prototype of a planning tool. The prototype featured a single view with all relevant planning data across desks, which allowed editors to make decisions in context. It also had status indicators that showed whether a step, like promotion on Facebook, had been completed.
We called it Project M, as a nod to the goal of putting management back into our content management system.
For two weeks, participating desk editors used our prototype to plan their report. This short experiment taught us about critical moments in the production process and points of high friction in the current system. It confirmed some ideas, like the need for a search result design that had a “show don’t tell” attitude towards story status and a way to capture a story’s priority. It gave us confidence in our direction.
One Planning Tool to Rule Them All
Using insights gained from the prototype, we built a planning tool, called Story Dashboard, that now lives permanently in our CMS. The dashboard pulls data from our core publishing system — the same system journalists use to write and publish stories. Editors can search for specific stories or stories relevant to their desks by using filters and keywords; Searches can also be shared with other people in the newsroom. The dashboard provides custom views based on user preferences, which editors can enhance with saved searches. This helps the newsroom find, organize and evaluate the status of stories, so editors can make decisions about their reports.
Show, don’t tell
We built a user interface that clearly shows the status of each asset, such as whether a headline has been written or if all necessary photos have been inserted. We found this to be more impactful and effective for communicating status than a tag marking the asset as done.
Clicking into a result gives more detailed planning and promotion information, as well as a live preview of the story.
Dates With Clearer Purpose
In a publishing ecosystem where a single article might be published several different times across multiple distribution platforms, a single publication date isn’t useful. To address this, we built separate digital and print publication date indicators. Editors can search for articles that fit whichever date type is most relevant to their work.
Because search functionality isn’t the best fit for every use case, we created a couple of specialized workspaces. We built a Planned workspace that shows all upcoming stories, grouped by publication date, for an editor’s assigned desk. At a glance, desk editors can see what work remains to be done for stories that are scheduled for publication on a particular date and they can plan for what’s coming up; To change an article’s publication date, an editor simply needs to drag and drop the story onto another date. Editors can optionally look at the stories that have already been completed.
Another key lesson we learned from Project M was that editors needed to see distribution feedback. It’s important for desk editors and social platform editors to be able to see whether a story has been promoted on a specific platform. Prior to the launch of Story Dashboard, this step required a lot of in-person communication, which could be challenging if numerous people were working on a story or if someone wanted to quickly get this information for all stories across a single desk.
Piloting and Iterating
We partnered with the Metro and Styles desks, and helped them move their planning flows entirely into Story Dashboard. Onboarding the first desks fully to our system further clarified what we got right and what we still needed to build.
A Calendar View
We enriched the planning capabilities of the dashboard by building a calendar view that gives editors a visual understanding of their week ahead. Editors can easily plan their short-term and long-term report in context and share plans with colleagues.
Editors told us that they needed a place to capture in-progress ideas for stories. There was no place to do this in our tools, which lead to fractured brainstorming and lost ideas. We built a workflow called Tentative into Story Dashboard to capture those ideas that are influx or might not run.
Newsroom planning is extremely complicated: it requires collaboration, transparency and a shared understanding of status. By consolidating all of our newsroom’s planning needs into one tool from disparate and unlinked systems enables everyone to have full context when making decisions. The easier this work is, the more our editors can focus on editorial decisions instead of wrangling administrative tasks, which makes The Times better for readers.
As digital production continues to evolve, so will the planning and promotion requirements of our newsroom. When workflows change, we’ll continue to build tools that help editors do their work efficiently and produce our daily print and digital miracle.
Angela Guo is currently the tech lead of the Workflow team at The New York Times.
The Workflow team is: Nathan Ashby-Kuhlman, Matthew Tanzer, Will Dunning, Jill Kacere, Matthew Clawson, Donna Rickles, Artur Charaev, Michael He, Lauren Peterson and Aaron Lee. Thanks as well to former project leads Tessa Taylor, Matt Berkowitz and Caroline Cox-Orrell, and especially to Johna Paolino and Kellen Henry who created the vision for this project and without whom this team would not exist.
Illustration by Jackie Ferrentino.
Source: New York Times