Team: Publishing - Workflow, The New York Times | Role: Lead Designer + Researcher
Hompage Variants
CONTEXT
OK, what’s a “variant”? Before we can talk about variants, we need to talk a little bit about an initiative called Programming as it was the catalyst for it in the first place. In Summer 2019, the newsroom took broad stock of our digital programming at The Times. They identified a significant gap between our ✨digital programming aspirations✨ and our current programming. Filling this gap is imperative to be the world’s preeminent digital publisher.
And so, Programming was born. The first order of business: getting rid of our existing system of programming The New York Times homepage.
What’s wrong with the existing system? Well, for one, the existing system was inflexible. The current workflow we have— “program once, deliver everywhere” — while serving its original purpose, imposed severe limitations that were hindering the newsroom’s ability to test, learn, and innovate. It’s our belief that, as the Times gets more sophisticated about knowing readers’ habits, which vary based on platform, time of day, location, etc., we need a system that would flexible enough to meet the readers where they are.
Unfortunately, right now fundamental, table stakes questions key to our business, such as “What is the right mix of news and features?” are unanswerable due to the rigidity of the current home screen structure, the lack of testing capabilities, and incomplete data.
Our hypothesis was that by improving newsroom flexibility, workflow, and product development speed to market we will address these issues and it will result in a robust, sophisticated end-to-end publishing system that can withstand the volatility of the media landscape and ever-changing needs of our audience.
This means we need to overhaul our existing publishing tool, Curator, and beef it up with lots of new sophisticated functionality.
What is Curator anyway? It’s the Times’ proprietary home page publishing tool created and maintained by the Workflow team. It facilitates the process of creating homepage “lists” which store homepage objects like articles, images, and interactives. It also allows the “Home Team” on our newsdesk to manage, preview, and publish the various sections of the homepage.
At the start of this project, Curator was limited to programming a single homepage for all readers. With the introduction of Variants, Curator would be able to not only manage many homepages but also test variants against each other in controlled experiments.
Pretty neat, huh?
DEFINING Key Problem Spaces
After exploring the existing news desk mental models, and taking stock of the current programming process through exploratory research, I identified that this problem actually spanned four discreet problem spaces and two key user groups.
To thoroughly examine the problem, I spent time having 1:1 sessions with folks on the newsdesk, supervisors, and adjacent Programming focused teams. My goal was to summarize the needs, desires, frustrations, etc., and identify the areas that created the most complexity so work could be properly prioritized.
Variant CONCEPTUALIZATION + ANALYSIS
Variant conceptualization turned out to be the most straightforward of the four user flows as there was no existing workflow or precedent. After presenting the journey map (see below) I recommended that the team create a team of data and newsroom folks who could conceptualize variant experiments that would be both visually pleasing and high impact to targeted users. With the help of product, we were able to prioritize forming this team and the “Optimization Team” now owns the Conceptualization phase.
Proposed User Flow for Variant Conceptualization Flow
As for Analysis, as we examined the end-to-end flow, we recognized that we would need to create a proof of concept for Variants before we could start work on a “Data Dashboard”. That work was removed from the immediate scope and responsibility was later transferred to our Newsroom Data team.
Variant Implementation + Management
Based on our conversations with the newsroom and homepage engineers, it was abundantly clear that we needed to focus on launching and managing variants over time. Not only was this user flow a block for all other Variants related work, but also because it would intersect an existing flow, it had the most existing pain points. We decided that hosting Variants inside of curator would be the best option for getting a proof of concept quickly spun up. It would also allow us to avoid introducing another tool to the newsroom workflow and it allowed us to work on some outstanding tech/design debt from the first implementation of Curator.
Proposed User Flow for Variant Creation and Publishing Process
High-Level Approach
Identifying the Desired Workflow
With our sights set on Curator, we began to brainstorm ways that we could learn more about how our users would react to Variants…without having anything to show them. We wanted to avoid “boilng the ocean” at all costs, but we also couldn’t “fail fast” as the business implications of a misstep would be massive.
I started with proto personas to see if I could glean any base-level requirements and get close to our MVP user needs.
At this point it was clear that we needed to optimize the existing Curator for accuracy and efficiency but how?
PROVOCATION TESTING
Provocation testing was a concept that came out of a discussion with my product partner. We were brainstorming “big ideas” and started wondering how the newsdesk might react to some of our wilder ideas: What if Curator was like TurboTax? What if Curator was like JIRA? What if Curator was like Pinterest?
It struck me that if we wanted user feedback, we needed to give them something to react to—the bigger the better. So we decided to mock up 3 new versions of Curator centered around 3 concepts:
Each concept was in some way a departure from the ordinary Curator and closer to another common CMS. For example, we modeled a highly visual WYSIWYG (what-you-see-is-what-you-get) version of Curator off of a hybrid of Figma, Google Maps, and Squarespace.
The results were surprisingly helpful. Obviously, it was a great tool to measure the preference towards each concept, but most importantly, it provoked our users enough for them to tell us how they really felt. Rather than accepting our “pretty good” attempts to create UI, they were obliged to tear down our purposefully slow, clunky, or overzealous versions of Curator. In the end, we didn’t walk away with a winning concept, but rather a list of priorities and “non-negotiables” for the newsdesk.
Respond to Key User Needs
After provocations testing, we were able to both narrow down our scope and requirements to focus on supporting our 4 key user needs.
For design, I chose to stick closely to Ink, our newsroom facing design system, and incorporate bespoke components only as necessary. This allowed for our engineers to provide quick mock-ups and get our MVP out the door
Ink Design System
