Feature Story Template
In Fall 2016, my team redesigned one of the most important storytelling products available to reporters at Vox Media, the feature template. The feature template is the template in Vox’s content management system that reporters use to publish their most high-touch, impactful stories—longform stories that take days or even months to report.
Before this project started, our platform was fragmented into many instances of the same product. As a result, my team had to support 18 different versions of the feature template. By the time this project was finished, we combined them into a single template product.
This project is part of my team’s larger, two-year initiative to unify every part of our eight brands’ websites (more than 350 separate sites in total) onto one platform that operates using a shared design system and codebase. I followed a similar process to unite a number of our storytelling products, including our storystream topic pages, search, and author/user profiles.
Before we get into the full case study, here is a quick look at feature stories before and after our redesign:
Unify the feature templates of eight brands into one single design and code system. Provide enough flexibility to create customized, branded longform experiences. Identify opportunities for smart enhancements to the template.
Our new template streamlines the editorial workflow, introduces a content-recirculation module, and offers four flexible image and headline layout options.
As a designer on the platform team, I worked on this project from research to production. I worked primarily with Josh Laincz (designer), Ally Palanzi (front-end engineer), David Zhou (engineer), and Chris Haines (project manager).
At the start of this project, feature stories across brands were similar at their core but differed in the details. Most feature stories had one large main image, a headline, and the story content itself, but diverged in their components, interactions, type systems, forms of navigation and links, and expression of their brand identity.
Here’s a quick sampling of past feature stories, with all their variations:
First, I audited feature stories to better understand their makeup. I approached the audit from both the end-user perspective (looking at the final components that compose a feature story) as well as from the editorial perspective (considering the templates and widgets editors had available to them when putting together a feature).
Some of the biggest variations were on the creation side. Across all brands, there were 18 templates and 81 unique code snippets editors could use to customize their stories. Many of the snippets didn’t work or duplicated functionality. Some of the templates shared the same name, but varied in actuality. We needed to clean them up.
Next, Josh and I interviewed more than a dozen editors and writers across our brands to learn about their process and pain points, for they were as much our users as our reader end-users. Here’s what we learned:
First, creating a feature was difficult. Editors had to resort to adding custom code or using workarounds and hacks to make feature stories work properly. “The system currently seems to be set up for designers and developers to do that work,” said one editor during our interview. “For me, it’s a struggle to even go in and change the color of some piece of text.”
Second, editors desired more flexibility with the feature template. One editor noted: “We want a way to signal that this is a big project, and it’s not going to look like every other page you’ll see.”
Finally, feature stories lacked in recirculation. Most simply ended with the final paragraph, halting users in their path. Editors wanted to capitalize on invested longform readers and guide them to additional stories. We had to consider holistically where feature stories fit in a user’s flow and how we could elegantly introduce a next step.
Once we had an understanding of the landscape and problems we needed to solve, I moved into designing the actual template. I designed brand-agnostically and focused on reducing the feature story to its basic building blocks. I used our research, as well as analytics of past feature performance, to inform the hierarchy.
Our engineers then built out the designs, and I worked with them to refine in code. I moved back and forth between lower and higher fidelity designs as needed.
Some of our solutions included:
Four top layouts. To give editors control over the look and feel of each feature, we gave the option to choose from four main image and headline layouts. Only the top portion is configurable; the rest of the story stays the same. As a result, editors feel like they have four completely different layouts to choose from, but all are easily maintainable from a product standpoint.
In our interviews, reporters told us that their current templates placed too much stock on the large main image. As a result, we decided to raise the profile of the headline in two of our four layouts (the first and second mocks below).
Simpler workflow. We introduced some functionality to relieve editors of tedious tasks, like a function our engineers built that automatically detects whether a dark or light logo should be used based on the brightness of the underlying image (fourth layout mock above). I also whittled the list of HTML snippets editors use to customize their stories from 81 to 43 options. I removed snippets that were rarely used, and incorporated some of the most commonly used pieces of markup into the actual product, like narrowing the content well.
Below are the criteria I made to reduce the list.
Better user flow. I created a new module displaying links to relevant stories in an attempt to recirculate readers to more of our content. Knowing that users are much more likely to reach the end of feature stories than articles, we decided to add this module three-quarters of the way down the page. We also omitted a full navigation bar up top in order to present a clearer call-to-action to users.
Finally, we worked brand expression into the product itself by designating specific areas (such as the colors and typefaces of the recirculation module) to furthering the brand. The result is systematic yet impactful.
This project required close collaboration between many teams. We worked with the story editor product team to ensure that our work lined up with their roadmap. We incorporated feedback and regularly communicated with our editorial teams.
Finally, we worked with the revenue team to come up with an ad strategy. Before our redesign, ads were basically nonexistent on feature stories. The redesign places ads in optimal slots programmatically, while giving reporters editorial control to override the placements as needed.
During our interviews, editors expressed concern about past feature stories that were built with custom HTML and CSS, which wouldn’t translate to our new template.
We came up with a solution that we called “cold storage,” which basically takes a snapshot of past feature stories and freezes them forever (or forever in Internet terms). In-progress stories could also go into this system. This piecemeal rollout plan built goodwill with reporters, helping them gradually adjust to the new template.
After eight weeks, we introduced the new feature template. We are supporting both old and new templates in the first few months, but eventually plan to phase out legacy templates entirely. Our editorial teams find that the new workflow is easier and more intuitive, and appreciate the ability to change the look and feel of a story without completely upending the entry itself. The recirculation module has been well received, and the opportunities for brand expression satisfies. Below are a handful of recently created features, all powered by our new template:
Because they’re built on our new platform, the template is also faster and more performant. Preliminary tests show a 58% decrease in Speed Index on mobile and a 28% decrease in Speed Index on desktop.
We still have areas we would like to improve. For instance, we did not have time to fully consider how to support differently sized image crops or ensure that headlines overlaid over main images remain accessible in all instances.
But we succeeded in creating one sustainable solution, built using an organized, maintainable design system, that meets the vast majority of our editors’ needs. We are set up well for future iterations.