Enabling editors, designers, and more to tell rich, immersive stories.
In 2017, Brit + Co’s editorial team was preparing to invest resources to create richer, more complex stories supported by beautiful multimedia experiences. In August 2018, we launched a beautiful, in-depth guide to buying the best fitting denim of your life.
Yet, editors couldn’t produce these high quality multimedia articles with Wordpress. And The Denim Guide was a bespoke, one-and-done effort, requiring a significant amount of design, engineering, and product resources. The back and forth workflow between editor, photographer, designer, and developer was painful for everyone, particularly right before launch. Editors couldn’t tell great stories on their own, nor at scale.
Our editors should feel empowered to tell the best story possible without reliance on engineering-heavy solutions. I was tasked with designing the MVP, then guiding the long-term vision for the user experience for a new internal editing tool and CMS.
Ultimately, our task was this: how might we design an easy-to-use tool that allowed editors, designers, photographers, and videographers to collaborate and build beautiful, high quality articles together?
We assembled a team of key stakeholders across editorial, product, and engineering. Throughout this project, I worked with our editorial lead Annette, our engineering leads, Scott, Julia, and Julie, along with our product lead, Shanan, to lead this project into reality.
First, we discussed how we wanted this tool to grow and evolve. After brainstorming, we came up with two key pieces to move forward.
The first was a product vision drawn from tools we loved, pain points we experienced, and hopes for the future. Ideas included Google Docs-like comments, Grammarly-like writing assistance, Medium-like layouts, and modules galore. Some principles we established early on were as follows:
Then we made a lean list of feature requirements for our MVP. We aimed to build a single guide by December, and to do that, we determined an editor should be able to…
This seems like a lot of features! But in reality, it was lean. 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.
Early on, we decided our engineering team would build a rough, workable prototype while I assisted editors in articulating vision for future guides and identifying potential future features. Our first prototype was largely a working wireframe that, well, worked.
As soon as we could add text, image, and video in our editor MVP, I worked with our editorial lead Annette to do usability testing. Our testing method was straightforward: we’d try to rebuild the static mockups in the MVP tool.
Our MVP was rough. First, 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. I funneled feedback to our engineering team and as they pushed fixes, we’d retest again.
By December, the MVP was still buggy, but we were slowly able to build a mock in the tool. Still, editors were frustrated. An editor would write a paragraph, only to have it saved over by another editor because we had no locking functionality. While we agreed as a team that we’d develop this feature after our MVP, 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. This proved our tool worked. 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 the MVP:
Our tool worked, but it felt rough around the edges. As we started work on building a slideshow editor, I seized the opportunity to start building a design language for the overall experience.
First, I conducted a UI audit on the MVP, noting particular UI elements, how they appeared, where they appeared, and how they behaved. After quick cataloguing (luckily the tool was still young) I established a basic information architecture for the tool.
Next, I began designing a visual language of color, typography, and scale for the tool. I approached this from two ways. Bottom up, I designed individual visual elements. For example, I established conventions and behavior for buttons and interactive elements.
Additionally, I tackled standard UI elements like dropdowns and inputs, ensuring they felt modern and cohesive with the primary interactive elements.
On the flip side, I took a holistic view of the system as I worked, ensuring that all elements worked together. This meant standardized spacing, a consistent monochrome color scheme, type sizes pulled from our living style guide. This brought the UI together and painted a cohesive experience for our user. You can see the Figma file and its evolution here.
Next up: we knew that for our tool to scale to a large amount of editors and contributors, it would have to be useful throughout the entire editorial process. One big gap: editing and publishing articles.
Next, I interviewed and observed our editors to discover what features we needed and uncover areas of improvement.
First, I watched our executive editor, Lesley, as she moved through her editorial process. Then, I observed our news editor, Allison. Whereas Lesley’s workflow spanned days and weeks, Allison’s was reactive, spanning anywhere from minutes to hours. Interviews with the two helped me identify areas we hadn’t covered.
In particular, we needed to develop a status feature for posts to indicate their stage from draft to published. We also needed to design a feature for scheduling posts for future publishing, along with adding comments to support the feedback and editing flow. Additionally, editors found themselves spending significant amounts of time editing HTML. We aimed to eliminate that unnecessary effort with smart engineering.
First, I tackled scheduling. We broke this out into two parts: the first taking advantage of baked-in browser UI, moving towards a custom date picker in the future.
Then, I worked on post status. I pruned status down to only the necessary steps. Then, I built upon our basic post index, designing filters to allow editors to quickly find articles that need their attention and work through their backlog.
Work is still in development. We’ve launched a browser-standardized version of scheduling, locking, and autosave. Post status is still in development.
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.