BuzzFeed CMS Editor

Laying a better foundation for Commerce data pipeline.

I designed a CMS editor form 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.

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:

• All the product data (such as price, retailer) are mixed together with our editorial copy. By providing more structure in data input, we can improve the data pipeline, leading to more detailed reporting that guide business strategy and editorial planning.
• The current format lacks flexibility. We believe more granularity will enable us to run targeted experiments, which allows us to learn quickly and continue to optimize how our posts serve our users while driving revenue.
• Tracking the editorial team’s progress against our promised paid placements is time-consuming and highly manual. A new format managed by tags can help automate this process and allow our editorial partner to be more efficient.

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:

• Populate data fields with product link
• Add and remove stand-alone title (we developed this concept for the item to be less reliant on the post context)
• Upload multiple images
• Edit product data
• Add, remove, and request tags

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 different features.

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 CMS 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:

• We should offer the flexibility for writers to freely move between each item without having to actively save or unlock.
• We should lean into the existing behavior of the CMS to help writers transition into the new workflow smoothly.
• We should group data fields in a way that allows writers to focus on the task at hand.

Sample workflows that we needed to support

• Text editing (leveraging the Rich Text Editor built by the Content Systems team)
• Image upload (up to 6 images)
• Alt text input
• Editing product metadata (after they have been populated with a product link)
• Adding optional fields when applicable
• Tagging

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 reduced the friction in the authoring experience as much as we could, while still collecting 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:

• What happens when the product link breaks? What actions can writers take to bypass it?
• What if a tag that a writer wants to include does not exist in the system yet? Should they be able to save the metadata regardless, or should they be able to request a tag to be added?
• Are there limitations in the CMS we should reflect on the frontend?

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.