Story Package Product

In July 2017, my team at Vox Media set out to build a new storytelling product—a way to create and present story packages.

Story packages are collections of related stories, united by some sort of central landing page. Each of our brands create severalofthesepackages per year, often as one-off custom designed and developed solutions. So while story packages themselves are well established in our newsrooms, creating them in our content management system was not.

Six months later, my team launched our MVP product: a responsive package “template” that reporters could use to create and display packages.

What’s so special about a template?

The template functions more like a system of smaller templates—designed to accommodate any number of stories, support myriad editorial strategies, and better serve our end-user audience members. At the same time, the template works within the confines of our platform and design system, and thus can be extended to our eight editorial brands and more than 350 websites.

Below you can see a selection of distinct published packages across networks that were created with this template.

The Team

Those of us who work on the CMS have two sets of users to consider: the editorial staff members who create content and the audience end-users who engage with that content.

I served as the design lead on the audience side of this project, and worked on the user experience, template system, and final visual design across our 350+ websites, Google AMP, and Apple News.

I worked closely with Katie Kovalcin, the design lead on the editorial side, who was responsible for the package creation flow in the editorial tool. Our core team also included a product director, project manager, and two engineers. (All other contributors to this project are listed here.)

Initial Research & Strategy

This project began as an editorial effort to give our reporters a way to associate and bulk publish stories in our CMS.As soon as I was brought into the project, I carved out a short research phase to understand the pain points and goals from the audience perspective. I reviewed analytics, parsed interviews conducted with our editorial teams, and audited several dozen previously published packages.

Examples of previously published packages (city guides, game guides, longform collections, and shopping guides) before we started this project

Insights

I found that most existing packages centered around something called the “landing page,” a homepage-like screen that introduced the overarching topic and linked to the various stories that composed the package. Most landing pages began with a lengthy introduction, burying links to the actual stories in the bottom half. At first glance, these landing pages seemed like our usual articles or feature stories.

It needs to feel special. It needs to say, this is something big.

— Verge editorial director

This meant that packages as they existed were tough for users to understand and navigate. Packages did not succeed in conveying that they were collections of multiple stories, prestige pieces of content, or merely a starting point to a plethora of content.

On top of that, our success metric—pageviews per session of package stories—was poor. People were not moving on to engage with additional stories.

The Problem & Hypothesis

Taking all this, I summed it up as this problem: Upon entering a package, our audience users want to continue on to interesting, relevant stories, but they either can’t find them or don’t know they exist.

And this hypothesis: This is because package stories are deprioritized, unconsolidated, and not well associated with the overarching package.

Designing the “Gateway” Direction

I explored a few different ways of solving this problem. The design direction we eventually landed on dedicates specific parts of packages to discrete purposes. This is a stark contrast to the open-ended way packages were made in the past, as well as how articles and feature stories are still made now.

The hope was that a more structured design would help users better orient themselves and find interesting stories—giving them a “gateway” to content at the onset.

We ended up going with this direction, and changed the project—the timeline, editorial tool, and expectations we set with editorial—to support this new audience experience.

The "gateway" design direction

Four Distinct Sections

Here’s a closer look at how the gateway direction prioritizes stories and package navigation on the landing page:

First we have a flexible, programmable top “cover” designed to draw users’ attention to stories straightaway

Next there’s a comprehensive “table of contents” index that shows all the stories in a package

Additional context about a package is shared lower down, in the “landing page body”

Finally, we have an eye-catching button that links to the first story in a package—our last effort to draw someone into the package

These sections can be emphasized or deemphasized to fit the needs of a particular package

Design, Test, Iterate

After we had the basic architecture in place, I began designing the details and worked closely with Katie Kovalcin and user researcher Gregg Bernstein.

Challenge #1: Accommodate myriad packages

Packages can vary significantly in terms of number of stories, types of stories, and edit strategies. They could be one story or 100 stories; guides or collections; highly visual or text-based. That meant creating one template layout, or even a set of layouts, would fall short.

Our solution: a flexible grid made up of stories. Stories have a few different display options, depending on how much emphasis editors want to give that story. By taking this modular approach, we are able to provide our editorial teams with virtually unlimited layout options that still follow a hierarchy.

Four sample layouts following the grid system

Challenge #2: Make packages feel distinct, without creating any new components

Packages—both packages within a brand, and between brands—need to feel distinct and special. But, due to our timeline, I was constrained to using only components (pullquotes, headers, buttons, etc.) that already existed on our websites.

In journalism, we tend to blow things up to signal they’re a big deal, so I decided to reign in this tendency by going smaller on the large screen display. This design is also different visually from all of our other story types and screens, making the landing page feel noteworthy at first glance.

Challenge #3: Convey that packages are a collection

Letting the user know that they’ve landed on a collection of stories was particularly challenging on small screens with limited real estate.

I added signals, like showing a peek of the first story and adding an “All Stories” link that links to the table of contents. These indicators both further the idea that users are seeing only one part of a larger whole, inviting them to explore more.

How the small screen cover designs progressed

Challenge #4: Balancing editorial flexibility with layout guidance

At the intersection of both the editorial tool and the audience-facing designs was the landing page layout tool. Katie and I worked together to find the balance between providing our edit teams with enough layout options and flexibility, yet baking in smart defaults and auto-layout features to ensure that putting together packages felt seamless and looked polished. This helps our reporters focus on the content, without having to worry about the user experience for the audience.

Visual Design

At Vox Media, we have a design system that maps specific components on our sites to CSS variables. I used our design system as a base for packages, but looked for ways to push the system further in our four largest brands—the Verge, SB Nation, Eater, and Vox.

I focused primarily on incorporating stronger branding elements and rethinking the use of type and color. I also tried to work around our branding limitations. For instance, I pushed back on using color combinations that were inaccessible, and thought about how to work around The Verge’s typefaces, some of which are tough to read at small scales.

Vox visual detail

Verge visual detail

SB Nation visual detail

The end result is meant to feel impactful, strengthen the distinction between brands, and between screens of the same brand (you can see packages in the bottom right corner).

Note the difference between The Verge’s packages (bottom right) and other story types

Creating consistency across platforms

Much of this case study discussed 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.

My biggest goals were to create consistency across these views and extend the visual language of our own platform.

Build & Launch

Our engineers started building out the template, and I worked with them to tighten it up in code.

Practically speaking, that means a single story can be depicted in multiple ways…

... with different levels of emphasis on story density (Polygon), navigation (Eater), and imagery (The Verge).

The system still looks and feels distinct...

... and is robust enough to power all eight of our brands, and more than 350 websites.

So, how’d we do?

For the first time on the product side, we are substantially changing the ways that our reporters tell stories. Packages are now easier for our audience end-users to use and navigate. They signal breadth, promote the actual stories, feel distinct, and overall provide a better user experience. And, due to my publishing colleagues’ work on the editorial tool, our teams will save significant time and effort in creating packages.

We only launched the template on four brands so far, but the results seem promising. Perhaps most exciting, we’re seeing a high rate of pageviews of package stories per session—meaning people go on to view more stories when they’re on packages as opposed to regular articles. On Recode 100, for instance, 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).

Further Reflection

While there are many areas we would like to revisit (such as allowing for more robust branding of packages), I’m excited about where we landed and the potential for this product.