A few months ago, we quietly released a new storytelling product out in the wild—a way to create and present collections of stories. The first story to launch as a collection was the inaugural “Recode 100” in December, followed by Vox’s “Understanding the Trump Era” in January, and just last week, Polygon published their game guide on “Monster Hunter: World.” While these packages are editorially distinct from one another, they are built on a six-month product effort to reimagine how we tell stories.
What’s a package?
Let’s back up for a minute and explain what we mean by “package.” We define a “package” as a collection of related stories, usually united by some sort of central landing page. Our brands typically create a handful of these packages a year—Curbed’s “On Race and Architecture”, Eater’s city guides, and Polygon’s game guides, to name a few.
To make them, our reporters would hack our feature and article templates, or developers would build an entirely custom page outside of our main platform. Both of these routes were time-consuming for both editorial and product, and resulted in one-off solutions that couldn’t easily be repeated with future stories. Plus, since these stories weren’t categorized as packages, we couldn’t easily get data about performance or audience behavior.
Let’s make a product
Our solution: build a story product that would help our editorial staff make beautiful, scalable packages.
The package product has two main components—the story editor tool that our editorial teams use to create packages, where they can add stories, lay out screens, and publish the entire collection at once; and the audience-facing expression of that tool.
The landing page as a gateway
Our main goal with packages was to get audience users off the landing page as quickly as possible and into actual stories. The landing page is essentially the “home page” for a package, usually outfitted with an introduction and links to various stories. To that end, we featured stories prominently.
In the past, when our reporters used the story template to make packages, they would start with a blank screen and construct the package however they wanted. Often, this meant that the landing page would begin with a lengthy introduction, with links to stories woven throughout the bottom half of the screen. Rather than simply reflect this same workflow for the package product, we made a bet on a better user experience that prioritized package navigation and story visuals.
The landing page is made up of four distinct sections:
- a flexible, programmable top cover designed to draw users’ attention directly to stories
- a comprehensive “Table of Contents” index that shows all the stories in a package
- a “landing page body” to provide additional context about the package
- a final eye-catching button that links to the first story in a package—our last effort to draw someone into the package
After we had the basic architecture of this screen in place, we began designing the details. Here’s a look at the progression of the mobile cover, informed by user testing, reviews, and discussions with our editorial teams:
Designing for ease in the story editor
At the other end of the experience, we had to figure out a way to make packages an easy task for our many editorial roles to build together. We needed to provide the right amount of control to make packages a distinct and unified new story type across our brands, yet allow enough flexibility for each package to have its own special experience.
This meant that we first had to define the entire architecture of how the story screens relate to one another, how editorial may be able to add and manipulate those stories on the landing page, and what decisions we would automatically make for them. Since we were creating a new story type from the ground up, we went through several rounds of user testing to fine-tune the robust organization of larger packages and clarify convoluted areas as we introduced new patterns and terminology.
At the intersection of both the editorial tool and the audience-facing designs was a critical component that needed strong collaboration from both ends to define: the landing page layout tool. We didn’t want to limit types or amounts of stories added to a package, so we needed a system that could respond dynamically to different combinations of content. We tried to strike the balance between providing our edit teams with enough layout options, yet baking in smart defaults to ensure that laying out the screens felt seamless and looked polished.
All together now
The result is a product that’s flexible enough to accommodate multiple needs—like different levels of emphasis on story density, such as the Curbed mocks on the left, or visuals, like Vox Creative on the right.
When we incorporated branding and visuals, each of our networks still looks and feels distinct.
This single product can thus be rolled out with great effect across our eight editorial brands.
Finally, we talked a lot about the landing page, but truthfully, that’s just one part in the package experience, a screen that plenty of folks may never even see. We considered and designed for all the touchpoints of a package, including stories that are part of a package, hubs and homepages that feature packages, and expressions on platforms like Google AMP and Apple News.
How’d we do?
We only launched packages on three brands so far, but the results look promising.
We wanted to see an increase in pageviews for package stories. For Recode 100, the average pageviews per session was high compared to our other Recode content (2.4 pageviews for package stories vs. 1.2 pageviews for articles). This means users on package stories consumed one page more than users on our standard article stories. In addition, the scroll depth of users on package stories were more likely to scroll halfway down the screen.
Not every stat was rosy. Time spent per page was lower than on our articles (folks spent 1 minute, 43 minutes, on average, on package stories, compared to 4 minutes on articles). In fairness, the Recode 100 stories tended to be short, which may have contributed to the less time spent.
From a product standpoint, we achieved our goal of creating an easier way for editorial teams to compose and publish packages, and we made a bet on a better experience for our audience. While there are many areas we would like to revisit, we are hopeful that we are in a better spot to iterate in the future.
This project is a joint effort by many people across Vox Product, including, but not limited to:
Publishing Team: Mandy Brown, Katie O’Dowd, and Aaron Parkening; Katie Kovalcin, with Holly Gressley and Kelsey Scherer; Nicole Zhu, with Billy Ceskavich, Dan Chilton, Nozlee Samadzadeh, and Blake Thomson; Gregg Bernstein; and Marie Connelly.
Audience Team: Priya Ganapati; Sanette Tanaka Sloan, with Jared Fanning and Yesenia Perez-Cruz; Ben Alt, with Ambika Castle, Greg MacWilliam, Pete Mall, Jason Ormand, Luigi Ray-Montanez, Jesse Young, and David Zhou.
Special thanks to Deep Adke, Jon Douglas, Nate Edwards, Zach Kahn, Krissy Kingwood, Steven Leon, Erik Luchauer, Nancy Seay, Sarah Taylor, Ashley Tsang, and all of our incredible editorial teams.
Shoutout to John Ratajczak, Yesenia Perez-Cruz, and Mandy Brown for their thoughtful edits.