In 2017, the product team found themselves encountering a few different, yet overlapping problems from stakeholders across the company.
As a business, we wanted to continue having a healthy diversification of traffic sources. We did well on Facebook, Pinterest, and Instagram, but we had room to grow in Google search results. Brit + Co articles were displaying in the Google News category, and these timely articles performed well. But, we hadn’t executed on a concentrated plan for gaining in rankings with long tail, SEO-rich content. We wanted to reinvest in our Google success, but our site was slow and garnered us a 60 on Google's PageSpeed Insights.
Around the same time, our editorial team was preparing to invest resources on richer, more complex stories supported by multimedia experiences that could complement this goal. Yet, editors didn’t have the tools to produce these initiatives on a large volume. Previous efforts had been bespoke, one-and-done experiences that required a significant amount of design, engineering, and product resources.
Our sales team wanted to sell sponsorship for these rich editorial packages, as they had a higher investment than a standard article. Our editors wanted to produce more, at a larger scale. And we as a product team wanted to empower our editors and sales team to make this happen!
So, I was tasked with designing the MVP, then guiding the long-term vision for solving these problems and making this product a reality. In classic design question, I aimed to answer the following question.
How might we…
We started with a aspirational idea: a fast, beautiful, visual storytelling frontend paired with an easy-to-use, WYSIWYG editor backend.
However, getting there would take time, testing, and a completely new workflow across the company.
We executed and built upon this new storytelling experience and editorial tools in three phases.
We had ambitious plans. However, we kept our first iteration simple. Our first iteration would test the following:
We assembled a team of key stakeholders across editorial, photo, video, product, and engineering to figure out what a new guide like this could be and how it would feel. Throughout this project, I worked with two editorial leads, Annette and Sharon, and one of our engineering leads, Scott, along with our product lead, Shanan, to lead this project into reality.
When we first imagined these content-rich, media-heavy, SEO-slaying articles, we didn’t really know what these things might look like when they’re smashed together. I took two approaches to narrowing down the massive scope of potential approaches.
First, I conducted competitive analysis into other SEO-heavy, media-heavy articles within the media space. What were other companies doing that claimed the top spot in key search results? On the flip side, what work of our competitors did we flag as stellar? By comparing and contrasting different approaches to solving similar problems, we flagged a few things we found appealing, like full-width images and videos, or interactive elements like quizzes.
After that, I acted as the idea generator for our cross-team collaborators. What might a new storytelling experience look like? How could we effectively use photo, video, and editorial content to tell a story? How can these experiences feel unique but also be scalable? How can this experience feel fast and dynamic?
The first exploration emerged from research I had led a few months prior. I interviewed readers from across the United States about their fashion and beauty interests, problems, and dreams. I pulled out a persona that prioritizes problem solving above all else, and I worked with our lifestyle editorial lead to do rough white boarding sketches for solving her problems.
This was an excellent exercise, as our editorial team had a guide to denim planned in the upcoming months. We prioritized this denim guide as our first test guide. However, wary of designing the perfect layout that fails everywhere else, I did further iterations.
Next, I explored upcoming stories planned on the editorial calendar, including a travel guide and a cookie guide. This range of content allowed me to flex my skills and push each idea to its best presentation. What would the best experience for each guide be? What similarities did they share, and how did they differ?
We settled on a few simple distinctions that would push these further than our current content:
From there, I built a desktop and mobile prototype of the denim guide in Codepen so we could see the video and animation functionality in action. As I prototyped, we moved full speed ahead with the denim guide production as our photographers and video team filming and photographing. And while I refined certain prototype behavior like the animating subnavigation, our engineering lead laid the groundwork for the production version of the guide, building a fast new framework separate from our current tech stack.
We continued to refine and iterate from initial wireframes to the day of launch. I’d replace dummy content, Scott would push a new version, Zoey would respond with feedback and edits, and the cycle would repeat.
The Denim Guide launched with much celebration internally and externally. Our initial traffic was modest, but we expected our traffic to grow over time due to the nature of an SEO strategy. Still, we learned a lot from this first version.
With those learnings in mind, our second iteration would test the following:
To test the ability to scale, we worked with key editorial contributors to determine two guides that could be developed around the same time with our new editorial tool. We determined that a video-heavy holiday cookie guide and a photo-rich holiday gift guide would be good for testing.
For the editorial tool and CMS, we worked with our engineering and editorial leads to finalize a list of features based off of our pain points with the denim guide and future needs for our upcoming gift and cookie guides.
We prioritized the following features. An editor should be able to…
This seems like a lot! However, we left many features on the chopping block, including previewing a guide before publishing, autosaving, deleting guides, and additional module requests like slideshows. For those, we kept a shortlist of requested features to add in the future.
For the first chunk of building the editorial tool, I had little involvement. The team discussed where to spend our time and decided that our engineering team would build a rough, workable prototype while I assisted editors in articulating vision for future guides. I’d hop in a little bit later to do basic usability testing to make sure the editorial tool was easy to use.
After working with editorial stakeholders to determine the bare minimum to make both guides successful, I embarked on competitive research for both the Cookie and Gift Guides to compare what content we’ve created in the past with what other media companies were producing. Then, I began to iterate.
My first design cycles consisted of acting as idea generator. I would work with our editors to develop potential functionality and layouts based on the stories they wanted to tell.
For the cookie guide, I iterated on a few video-heavy layouts that complemented the initial structure of the denim guide. We quickly found that additional features such as a more visual overview of how comprehensive this guide was — we called this the Table of Contents — and a module for recipes would help structure the content in a more digestible, skimmable way.
For the gift guide, I explored a few different options, but had a lot of difficulty making the denim guide layout work. We explored a few different directions, and some potential new products, but ultimately concluded that the requirements for the gift guide differed too far from the denim and cookie guides.
After iterating on both, we concluded with a final mock for the cookie guide including two new features: a different visual layout for chapters including a Table of Contents, and a recipe module.
As editorial and I settled on a layout, our photo and video team began documenting the cookie making process — one of the great perks of working at Brit + Co. Engineering delivered an MVP of the editor experience, with the ability to add text, image, and video throughout the guide. I worked with our editorial lead to test the initial editor tools and we’d keep testing as new versions were released. Our testing method was straightforward: we’d try to recreate the static mocks using our new tool.
I’ll call this our alpha. Our alpha contained a few usability issues: some buttons and text areas were not easily clickable. Our edit and delete button were too similar, and editors often mixed the two up, accidentally deleting content. Input labels were vague and unclear, and we had no error handling. We made notes and incorporated fixes into future versions, or noted what would wait for later.
We encountered another problem as stakeholder requirements changed shortly before launch. The problem in question was the Table of Contents module. I’d iterated on a few versions, and the one we chose was big and beautiful. However, it worked best for guides with 2–8 chapters — our proposed limit. However, new sponsors arrived at the last minute and pushed our chapter number to 11. The Table of Contents was simply too long on the mobile experience. At the last minute, we reverted to an earlier design to handle a larger, more dynamic number of chapters. I worked with an engineer, Julie, to design a dynamic grid that accommodated any number of chapters from 2 to 20 that worked for most on desktop, tablet, and mobile experiences.
Even despite this, the MVP editor tool was still a little buggy, and editors were frustrated with the lack of locking functionality. We agreed as a team that we’d develop this feature after our MVP. Still, it’s one thing to know something in the abstract. It’s another to have another editor save over hours of your own work!
By launch date, we successfully published our Holiday Cookie Guide, a rich multimedia experience built with our new editorial tool. We saw success with individual creative assets across multiple social channels, and we’ve seen this cookie guide creep steadily upwards in SEO rankings.
Overall, this guide was a successful proving ground for our new editorial tool and CMS. Despite its MVP-ishness, it fulfilled its initial requirements — and it was a champion of a new, fledgling format of cross-team collaboration.
Our takeaways from this version:
We were starting to hit our stride. We’d designed an editorial experience that scaled across different topics and interests. The first version of our editorial tool worked, even if it was a little rough around the edges. For our third iteration, we would focus on two things:
At this point, we were fielding feedback from our editors that were using the tool daily. We’d prioritized engineering-heavy features like autosave, locking, and preview as key to scale this tool for the next group of users.
And in an effort to try to build new formats in our editor tool, I took a stab at designing a better workflow for slideshows. I documented this in the following case study and early feedback and input turned out well.
So, my final focus landed on polishing down some of the tool’s rough edges.
To start, our tool was a little visually rough. There was no consistent vision for how it should look, feel, or respond to a user. It felt haphazard, broken, and unpolished.
I tackled the challenge of creating a visual language for our editor tool. I took both a top-down and bottom-up approach to ensure the whole would feel as cohesive as its parts.
I pulled together some common layouts, including the guide builder and the CMS index. Then I iterated on a few color schemes, played with balance and spacing to get the overall feel correct.
Then, I took a look at smaller, common components like buttons, inputs, and dropdowns, tweaking each individually to make them shine while ensuring they feel cohesive and a part of the system.
Through multiple rounds of tweaking and iterating — throw a button style into this sprint, build a table layout in that sprint — we iterated to the polished tool it is today. There’s nothing glamorous here. Just a lot of iteration and long-term tweaking.
There’s one other point of success I’d like to note. This may not seem like a key component of the design process — however, it was key to helping new editors learn a new tool and feel comfortable in a new workflow.
To increase editorial tool adoption at a larger scale, I did the following:
This process may not translate into sexy, beautiful button styles, but it did translate into a better product. Feedback from these sessions helped us create a better on boarding experience, choose more accurate form field labels, reprioritize features like autosave, and revisit confusing flows, like selecting a particular chapter layout. And I expect that these conversations will continue to help us scale and build a better tool as we move forward as a team.
This project is a work in progress, and while some successes will only become apparent over time, I would like to note immediate victories.