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.
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.
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:
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.
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:
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.
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.
I extended the existing visual styles of the CMS; here is a sample of my explorations:
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.