By Hagai Itah, Senior Product Designer at Minute Media
The following is an article that originally appeared on Minute Media’s Tech Blog.
In 2015, Minute Media released its Editor to more than 200 writers and 20 content managers. For the next two years, thousands of articles were only curated and published to 90min, our first football-focused brand.
Since then however, the company has grown and added multiple brands to its portfolio , such as The Players’ Tribune, FanSided, The Big Lead, 12up , DBLTAP, Mental Floss & TheDuel (in partnership with FanDuel).
This meant that writers and content managers across all of these brands were using the same Editor launched in 2015, which was originally conceptualized to fit the needs of only one specific brand. It became obvious that the Editor was outdated and needed an overhaul.
In this post, I’ll discuss the process we underwent as a team, the challenges I faced as a product designer, and the issues we solved along the way to define and design our new state-of-the-art Editor.
Defining the problem
Multiple issues became more and more apparent as we began our research into creating a new editing platform. Firstly, the Editor’s user interface was designed based on 90min’s look and feel, so did not meet the needs of our other brands which span across different content verticals . Secondly, the Editor’s article output was HTML, which in technical terms, is far from ideal. In order to support additional content formats and create more flexibility in user experience, it had to be changed to JSON.
In addition, the old Editor platform posed challenges when it came to monetization. The editor WYSIWYG created empty paragraphs which prevented optimizing the ad performance and element integration. Furthermore, the Editor has an unforgiving nature, which negatively affects the user experience. Any error a writer made when placing an image forced him/her to delete, re-upload, and reposition it before achieving a simple positional change. Whether it was from our editorial side or from the company’s strategic perspective, the Editor made it very difficult for us to scale our content.
As a product designer, every new project starts with research. After scanning the market, I got inspired by famous and universally established editors such as Medium, Storify, Wix, Behance, & Squarespace. They are all well thought out, unique, and are able to serve different audiences. In fact, several features in our new Editor are based on some of their functionalities.
In addition to analyzing the market, I studied the habits and behaviors of our in-house editors and writers. I shadowed them while they created articles and held countless interviews with our editorial teams, in which I asked about their experiences with the product, their impressions of use, their main pain points, and the features they liked and/or would like to see improved. I also sent out a survey to our editorial teams in other global offices (UK, US, Brazil) asking for their feedback and ideas on new features, templates, etc.
It was important for me to involve all of the editorial teams in the process, because the new Editor we were creating had to be better than the original, and what better way to make the best editorial product, than to create it from an editorial lens?
One of the main takeaways from our research was the editor’s need for a drag & drop solution when forming articles. More than 66% of all participants were looking for the ability to reorder paragraphs and media items within the Editor. This led us to take a block-based approach when conceptualizing the editor.
Think generic, think scale
Since Minute Media’s vision is focused on creating an open platform for any publisher in need of publishing tools, we created the editor as a stand-alone product. We reshaped our design and adapted our platform with a common visual language, color hierarchy, component behavior, layout and grid which we can customize and update easily.
Because we are dealing with a storytelling product, we used a one-third-two-thirds layout. The two-thirds are used for the writing functionalities canvas and the one-third allows the user to insert any type of media to the article. Because this product will be licensed out, we added functionalities in order to facilitate the article creation flow. There is now a progress bar above the writing canvas, guiding the user through the different steps they need to take in order to publish an article. The sub-header not only includes the progress bar, but moreover, tooltips, a saving indication, and CTA buttons.
It forced us to think systematically and generically about where to write a new paragraph, how to edit text, how to add media to enrich the content and where the writer can see their process.
From article templates to content blocks
The original editor supported multiple article templates. These capabilities were added to allow writers to increase content variety, and differentiate our platform from traditional publishers. While the idea certainly had merit, several problems became more apparent over time.
Firstly, as mentioned earlier, the unforgiving nature of the editor meant there was no way for you to go back and change the template if you had already started writing the article. You would have had to restart a new article and copy&paste the contents. Another challenge was the layers of code needed to support several templates. Over time, when more article templates were added, this led to a complicated product with a lot of bugs and issues and high maintenance costs.
What I realized during the research, was that every article template had key features in common. They all needed a cover image, a title, article tags, & SEO descriptions to improve the ranking of the article search engines. In essence, the differences from template to template entailed changes in the article body. The question arose: why should the writer have to choose an article template before starting to write? This is when we made the difficult decision to completely overhaul our approach and conceptualize one single article type, out of which the user would be able to create multiple templates by adding different content blocks.
Convincing everyone involved in the project to move away from templates, in favor of this new concept was difficult. Templates had been the bread and butter of the editorial team for years. Our new approach, however, gives the editors more freedom, room for creativity and responsibility to write new types of articles they couldn’t before.
The new block-based editor won’t change the way any of our content looks to our readers. What it will do, is let the writers insert any type of multimedia in a snap and rearrange it the way they please. Each piece of content will be in its own block; a distinct wrapper for easy maneuvering.
If in the old editor it took days for the developing team to add a feature, in the current editor we’ve made sure to create generic infrastructures to guarantee easy scalability. While it took developers days to add the ability to embed different social media into our article, the same task only takes a few hours today.
My main goal through all this process was to create a very intuitive product with no specific and no unknown behaviors, which allows us to scale the editor with the ability to add new features and to improve the product along the way.
Many of our choices have been warranted so far, as we have received positive feedback from our teams using the product since its launch in December. A further vindication for our approach has been WordPress’s new editor release (WordPress 5.0 “Bebo”). Their biggest change was similar to ours, an approach which included content blocks.