Readers visit Brit + Co to experience beautiful visual storytelling. In early 2017, we launched our slideshow MVP. It proved to be a hit. Engagement increased across the site and readers loved the collections of rich, beautiful photography paired with knowledgable storytelling.
In the spirit of following a lean, iterative development process, our engineering team piggybacked on existing Wordpress features to enable our editors to compose their own slideshows. However, editors found creating slideshows to be a frustrating, painful process, despite the increase in readers and time spent reading.
Our editor Lesley put it keenly: “I’d rather spend 30 minutes writing a basic article than spend 2 hours editing a slideshow.” Ouch.
I was tasked with solving the following dilemma: how might we help editors create slideshows in a faster, more efficient way? Additionally, could we — dare I say it — make the experience enjoyable?
Throughout this project, I worked with Lesley, the key stakeholder from our editorial team, to identify problems, prototype ideas, and test solutions throughout the development process.
I sat down with Lesley to watch her current slideshow-building process using Wordpress. I then observed 4 other editors across our affiliate, beauty, and style departments to compare and contrast their behavior. Every editor had their own unique process, yet several key themes emerged.
I explored a few options and presented two to engineering stakeholders, product stakeholders, and editorial stakeholders.
Option A piggybacked on a WYSIWYG slideshow technology we developed to do visual dynamic storytelling for Brit + Co’s Year in Women project. Advantages included a unique, highly visual way of storytelling that felt modern and contemporary. One stakeholder described this as the “Instagram stories” option. However, this option would require editors with a keen visual eye, excellent layout skills, and a willingness to put in additional time to explore a new format of storytelling.
Option B required new technology development and presented slideshows in our current frontend display. While we’d need to develop a new backend tool, we could utilize the current slideshow frontend, and we could replicate current editor workflows to make the transition seamless and fast. However, slideshows would retain a more traditional look and feel.
First, I consulted with stakeholders. All groups initially desired the inventive outcome of Option A, but agreed that the tool would be more time consuming for editors. Additionally, it would require staffing for editors with excellent visual design skills and many contributors had limited abilities. In the end, all concluded that the practical Option B would be the best fit for our business and the stories we were currently telling.
Around the same time, I conducted a basic, clickable user flow test with Lesley, our editorial stakeholder, observing her walking through the flow. While most of the flow went smoothly, Lesley’s choice to upload multiple photos at once encouraged me to flag batch uploading as an MVP feature.
With these pain points in mind, we finalized the following features to solve for our first MVP of slideshows.
With this, we began development. There was one nice bonus here: working with this module allowed me to pitch a united style guide for our internal tool. We were able to neatly tuck those refinements into this project.
We launched our slideshow editor with a handful of internal editors building slideshows from scratch. Editors had a few asks, including the ability to open a linked article directly from the slideshow editor, keyboard shortcuts, and an affiliate link converter. Overall, initial feedback and response has been incredibly positive.
While we continue to refine and iterate, overall we've reduced pain for our editors, and with that, it has been a smashing success!