DIGITAL DESIGN

THE ARTICLE EDITOR

THE ARTICLE EDITOR

By far the most ambitious product created for the CMS also happened to be the first: the article editor.

By far the most ambitious product created for the CMS also happened to be the first, the article editor.

BRAND

Mic

ROLE

UX Design, Interface Design, User Research

YEAR

2015

What do you do when you’re a new media company trying to innovate how news is delivered but don’t have the tools to make it happen? Mic was the new kid on the block with a lot to prove. We needed a CMS to create, edit, and distribute articles effectively and pave the way for whatever lay ahead. At the time, there were some editing platforms we could utilize, many SaSS offerings that could be leveraged for data insights, and services that offered different ways to view analytics, but we wanted one toolset that worked for our specific needs, and it just didn’t exist. So the question became, could a lean product team create a CMS that could fulfill all of the needs of a growing media company?

What do you do when you’re a new media company trying to innovate how news is delivered but don’t have the tools to make it happen? Mic was the new kid on the block with a lot to prove. We needed a CMS to create, edit, and distribute articles effectively and pave the way for whatever lay ahead. At the time, there were some editing platforms we could utilize, many SaSS offerings that could be leveraged for data insights, and services that offered different ways to view analytics, but we wanted one toolset that worked for our specific needs, and it just didn’t exist. So the question became, could a lean product team create a CMS that could fulfill all of the needs of a growing media company?

This product was responsible for creating every article published and helped Mic transition from a company with something to prove to a company to watch out for.

The Problem

Constant crashes, lost work, text styling issues, and broken video embeds; these were just some of the issues that were plaguing Mic staff with the article editor on the platform. The core issue was that we (and most of of the media world) were working with hacked together tools in order to get articles onto our site.

Constant crashes, lost work, text styling issues, and broken video embeds; these were just some of the issues that were plaguing Mic staff with the article editor on the platform. The core issue was that we (and most of of the media world) were working with hacked up tools in order to get articles onto our site.

Users & Audience

For the most part, our writers and editors knew what they wanted and needed in order to publish great content. These were the people that would be using the editor everyday so making sure that they were satisfied with the product was key. In turn, we had an excellent pool of people from which we could source requests, feedback, and test new iterations on.

For the most part, our writers and editors knew what they wanted and needed in order to publish great content. These were the people that would be using the editor everyday so making sure that they were satisfied with the product was key. In turn, we had an excellent pool of people from which we could source requests, feedback, and test new iterations on.

Team & Role

The design team was just me and an intern, so my role on this product was multi-faceted. I was researcher, strategist, UX designer, and project manager. I was lucky to work with three talented full-stack developers and the five of us figured out how we would bring this product to life.

The design team was just me and an intern, so my role on this product was multi-faceted. I was researcher, strategist, UX designer, and project manager. I was lucky to work with three talented full-stack developers and the five of us figured out how we would bring this product to life.

Process

Collectively it was decided to approach the process in a traditional waterfall method in order to launch a functional MVP as soon as possible, then iterate. The lead developer and I devised a simple timeline with areas to research, design, iterate, build, test, and release with the goal of launching within 4 months of the start date.

We identified a group of key stakeholders consisting of writers & editors that we could rely on for functionality feedback and core usability testing. We interviewed ten active users to gain insight into pain points, ideal workflows, and suggestions. Together, we identified a few key points. 1) We found that most people were frustrated that the current editor would crash often. Out of 10 articles published, 6 would crash while publishing and the data would be lost. This resulted in hours of lost work, so they had shifted their workflow and worked primarily in a local editor and then would copy/paste into the Mic’s editor when they were done. 2) This resulted in another pain point: styled text from their local editor would render incorrectly when published. 3) Editors were frustrated that writers wouldn’t fill in required information which would result in additional time to publish. 4) We received a few great requests: inline commenting threads, revision history, auto-suggested tags, adding multiple authors, and allowing smart media embeds like tweets & YouTube videos. These were all requests we felt deserved to be incorporated.

Collectively it was decided to approach the process in a traditional waterfall method in order to launch a functional MVP as soon as possible with the plan to then iterate later on. Paired with our lead developer, the two of us devised a simple timeline with areas to research, design, iterate, build, test, and release with the goal of launching within 4 months of the start date.


We identified a group of key stakeholders consisting of writers & editors that we could rely on for functionality feedback and eventually core usability testing. We interviewed ten active users to gain insight into pain points, ideal work flows, and what could be improved. Together, we identified a few key points. 1) We found that most people were frustrated that the current editor would crash often. Out of 10 articles published, 6 would crash while publishing and the data would be lost. This resulted in hours of lost work, so they started to shift their workflow and work primarily in a local editor like Microsoft Word and then would copy/paste into the Mic’s editor when they were done. 2) This resulted in another pain point, styled text from Word would render incorrectly when published. 3) Editors were frustrated that writers wouldn’t fill in required information which would result in additional time to publish. 4) We received a few great requests; inline commenting threads as seen in google docs, revision history, auto-suggested tags, adding multiple authors, smart media embeds like tweets & youtube videos, in addition to others. All requests we felt deserved to be incorporated.

So with all of that data we had acquired, we then asked ourselves, how will we measure success?

1. When we have a reliable publishing platform that doesn’t crash.
2. Once we’ve established a system that makes editorial staffers’ lives easier on a day to day basis.

The goal was to create a simple system that was easy to use without any guidance, while including all of the functional tools that our editorial team needed. I did market research to review what others in the space were doing, both to pull good ideas from and to note what isn’t working. We looked at what products like Medium and Ghost were releasing and referenced any ideas that we believed worked well.

So with all of that data we had acquired, we then asked ourselves, how will we measure success?

1. When we have a reliable publishing platform that doesn’t crash.
2. Once we’ve established a system that makes editorial staffers’ lives easier on a day to day basis.

My goal was to create a simple system that was easy to use without any guidance, while including all of the functional tools that our editorial team needed. So I did some market research to review what others in the space are doing, to pull good ideas from and to note what isn’t working. We looked at what products like Medium and Ghost were releasing and referenced any ideas that we believed worked well.

User Flow

I wanted the article creation system to feel unconfined yet linear. I worked with stakeholders to map out how an article can go through the editing process with minimal friction. The process would be simple; a writer would log into the CMS and could immediately start populating a new article in a highly visual way. Styling text would be as simple as highlighting and then clicking one of the options from the popup styling bar. Most writers had a hard time moving paragraphs around due to the limited screen resolution of their laptops, so we allowed for easy paragraph reordering. If a writer wanted to add in an image or video, they simply had to hover between to paragraphs to introduce an add media button. Media could be embedded using a link or a writer could search for images through a custom image database populated by Getty or AP images (all built in-house). To the editors' delight, writers were required to populate certain fields. Once done, a writer could submit the article and an editor would then be notified that they have a new article in their queue. The editor would be able to make their edits (the writer would be locked out) and add comments directly inline and send back to the writer. After the writer made the changes and all had been approved, both parties would be able to preview the article on mobile and then publish to the site.

Because the editor had to work for both writers and editors, we needed to figure out an ideal user flow. I worked with stakeholders to map out how an article can go through the editing process with minimal friction. I wanted the article creation system to feel unconfined yet linear in function. The process would be simple; a writer would log into the CMS and could immediately start populating a new article in a highly visual way. Styling text would be as simple as highlighting and then clicking one of the options from the popup styling bar. Most writers had a hard time moving paragraphs around due to the limited screen resolution of their laptops, so we allowed for easy paragraph reordering. If a writer wanted to add in an image or video, they simply had to hover between to paragraphs to introduce an add media button. The media could be embedded using a link or a writer could search for images through a custom image database populated by Getty or AP images (all built in-house). Writers were also required to populate certain fields like the editorial section the article would appear in and add a byline. Once done, a writer could submit the article and an editor would then be notified that they have a new article in their queue. The editor would be able to make their edits (the writer would be locked out) and even add comments directly inline and send back to the writer. After the writer made the changes and all has been approved, both parties would be able to preview the article on mobile and then publish to the site.

Wireframes

Once we had the flow approved, we moved into a wireframing stage. Because this was going to be the first major product build for the company, I decided to mockup wireframes in high fidelity in order to express functionality clearly to all stakeholders. We ended up with 11 versions of wireframes in a 4 week week timespan. The wires were created in a storyboard format, taking the viewer through a typical article creation flow that would highlight all major features of the product.

Once we had the flow approved, we moved into a wireframing stage. Because this was going to be the first major product build for the company, I decided to mockup wireframes in high fidelity in order to express functionality clearly to all stakeholders. We ended up with 11 versions of wireframes in a 4 week week timespan. The wires were created in a storyboard format, taking the viewer through a typical article creation flow that would highlight all major features of the product.

article editor early wireframes

UX Design

Because we wanted a clean, straightforward design, we only had interface interactions appear when needed. This allowed users to have all the tools necessary available whenever they needed and not hidden away in any menus. We focused the product on the core group of users who would primarily be writing from a desktop or laptop computer with the goal to support mobile in a future release, allowing ourselves to focus on the best user experience possible for the biggest group of users.

Due to us wanting a clean, straightforward design, we only had interface interactions appear when needed. The added bonus was that it allowed users to have all the tools necessary available whenever they needed and not hidden away in any menus. We focused the product on the core group of users who would primarily be writing from a desktop or laptop computer with the goal to support mobile in a future release, allowing ourselves to focus on the best user experience possible for the biggest group of users.

Article Editor – wireframes v9

UI Design

Our UI ethos was to be unobtrusive but highly functional. Because the editor would display the article just as it would when published, our brand’s typefaces were fully integrated into the title, byline, and body of the editor.

Our UI ethos was to be unobtrusive but highly functional. Because the editor would display the article just as it would when published, our brand’s typefaces were fully integrated into the title, byline, and body of the editor.

Screen Shot 2019-01-23 at 4.59.37 PM
article editor – Search Overlay
editor – features

Build & Release

The editor was coded entirely from scratch without using any libraries or pre-built modules. Before release, we launched the new editor on a staging server. We tested on every available browser on both Mac OS and Windows machines anticipating any scenario and edge case that might arise.

The editor was coded entirely from scratch without using any libraries or pre-built modules. Before release, we launched the new editor on a staging server. We tested on every available browser on both Mac OS and Windows machines anticipating any scenario and edge case that might arise.

editor – reordering
editor – errors

Outcome

The reaction of the first phase article editor was incredible. Our editors and writers loved the editor and all of its capabilities. Many were coming straight from competitor outlets and hadn’t expected that tools would be created to suit their needs. After released, we iterated on the editor for roughly a year and a half, constantly refining features or adding additional ones that were requested. We quickly added in the inline commenting feature which allowed editors to comment on specific sentences or words and start a thread with the writer until the issue in question was addressed. We added in revision history so that a writer could go back in time and recover any drafts that they had previously deleted. Our most useful addition was adding in the ability to view the current article draft in mobile using Slack. This helped reduce additional layout revisions and also allowed for faster approvals between editors.

The reaction of the first phase article editor was incredible. Our editors and writers loved the editor and all of its capabilities. Many were coming straight from competitor outlets and hadn’t expected that tools would be created to suit the application they needed. After released, we iterated on the editor for roughly a year and a half, constantly  refining features or adding additional features that were requested. We quickly added in the inline commenting feature which allowed editors to comment on specific sentences or words and start a thread with the writer until the issue in question was addressed. We added in revision history so that a writer could go back in time and recover any drafts that they had previously deleted. Our most useful addition was adding in the ability to view the current article draft in mobile using Slack. Using the Slack API, we added a preview button in the bottom toolbar that would allow users to search for their username and send a preview link to their phone. It helped reduce additional layout revisions and also allowed for faster approvals between editors.

NEXT PROJECT