BuzzFeed CMS Editor

Laying a better foundation for Commerce data pipeline.

I designed a CMS editor format to help the market editorial team collect and store more structured product data. This is part of the foundation work my team took on to unlock key business opportunities and was a precursor to our redesign of the BuzzFeed Shopping vertical.

Role
Product Designer
User Researcher
Timeline
12.2020 - 03.2021
Team
1 Product Designer (me!)
1 Product Manager
3 Engineers

with support from the Content Systems Team

Context & Goals

With shopping posts being a fast-growing part of BuzzFeed's revenue stream, we felt the need to improve the technology powering our content to help them reach their full potential.

In BuzzFeed’s homegrown content management system (CMS), Market writers utilize regular text or image format in the editor to compose shopping posts with product recommendations. Over the last few years, we have seen exponential growth in the affiliate revenue driven by these posts. We felt the need for evolving the current format to give more structure to the product data we are collecting and saving, which will help lay the foundation for how we better create, store and surface product content.

Specifically, we have identified the following opportunity areas:

Editorial leadership will socialize the new format among writers, who are our end users. For our writers, I also wanted to make sure this new workflow is easy to ramp, introduces minimal friction, and enables them to optimize for efficiency.

Solution

The new product editing format is a form featuring a series of product data fields and is connected to the tagging system to store more structured commerce data.

In this new form editor, writers can:

Definition

Leading up to this project, I led a team brainstorm to gather idea for the new CMS format to provide better support for various use cases - rendering useful content to our readers, improving our data pipeline, enabling writers, and unlocking opportunities for our team to build more features on top.

Aligning business needs and co-creating with our users

After discussing the data needs with our editorial and business stakeholders, we had a kickoff with our engineers to prioritize the different features.

From previous interactions with writers, I learned a lot about the general editorial workflow by conducting interviews & contextual inquiries, shadowing their All Hands, and reading their writing style guide in detail. This time, in order to zoom in on their unmet needs with the text editor, I prepared a series of building blocks and asked the writers to construct their ideal version of the input form.

Here are samples of the artifacts writers co-created with me:

Some of my high-level learnings included:

1. Writers often work in a nonlinear process, finishing an article in piecemeal.

Many writers start by putting in placeholders for a general idea of an item, and once they are satisfied with the overall flow of the article, they would go back and add in the details.

2. The ideal version of form takes shape of an extension of the current editor.

3. When writers are zoomed in on one item, they prefer as little distraction as possible.

To me, these meant that:

Sample workflows that we needed to support

Design Iterations

Optimizing for efficiency in writing

Knowing that the new form will have more required fields, I wanted to make sure the workflow I design enables writers to make the best use of their time. In a check-in meeting with my engineers, I learned that it could take 30 - 45s for our backend system to pull in data from a product link, so we moved the link to the top of the form, so that the data can load as writers flesh out other content areas.

We also examined each "required" field to make sure we were setting up minimal restrictions while still making sure we collect useful product data. For example, we tweaked the form requirement from writers having to enter all three fields under “subbuzz information” to requiring 1 out of the 3 fields. This allows our writers to flow across different items more freely.

Another major design consideration for me was lowering the interaction cost. For example, one of the workflows we wanted to support was for writers to add in a field when applicable. For this use case, I explored a few options (open field, explicit saving action, modal) and ultimately landed with the first direction because it requires the least amount of navigating back-and-forth using a cursor.

Taking care of less common use cases

I mapped out a flow diagram for the tasks handled by writers and the CMS, respectively.

This exercise led to more detailed considerations, such as:

I then crafted the copy for possible error messages and helper text, as well as work with my engineers to build "fallback" features - such as allowing users to enter product metadata manually when the data fails to load with the link given.

Establishing a visual language

I extended the existing visual styles of the CMS; here is a sample of my explorations:

A set of visual explorations for form loading state

A set of explorations for a status label

Learning from Soft Launch

We onboarded 3 writers as the initial soft launch to get feedback on performance bugs and any usability issues. In addition, we also heard from writers that this new format needed to be better integrated with how it interfaces with other commonly used CMS features.

As of July 2021, we have onboarded the entire Market Team (~40 writers), who are currently utilizing this new format to populate and manage content for our redesigned Shopping vertical (buzzfeed.com/shopping). With the more flexibility this format offers, our team is also currently designing and running smaller experiments on article pages.