A two-year project to design a completely new web browser-based publishing system, built entirely without any third-party systems or frameworks. Increased the speed of publication by 30% against our initial benchmark.

The challenge

The existing 7-year old bespoke CMS posed various problems, for example:

• For reporters: Dealing with obscure formatting codes, layout conventions and concepts.
• For editors: Lack of control over articles in progress, disjointed video and news hub editing.
• For IT and support: Staff training in a rapidly expanding organisation; bug fixing outdated underlying technologies.

Specific challenges for the design of the new system also included:

• Understanding the often diverse publishing workflows that existed across the organisation.
• Producing a system that worked for both the managing editor and his staff.
• Reducing the need to spend time training new reporters, who needed to get working as soon as they arrived.

In addition, we couldn’t take journalists and editors away from their work for more than a few minutes at a time. There were no meeting rooms, much less a culture of meetings, so feedback was to be ad hoc, at the people’s desks, discussing and showing them ideas and incremental improvements.

Fundamentally, we needed to make a CMS that was substantially easier to use than the incumbent.

Understanding scope and key use cases

Unlike other online publications, MailOnline gave responsibility to reporters for creating both copy and headlines, as well as in selecting photos and videos. All this was done in the name of speed. Stories needed to be easily put together, previous stories found, photos and videos placed, cropped and captioned. The Publishing Director was also against all forms of machine-assistance in editorial tasks (article recommendations and sorting, link generation, etc.).

Editors then needed to collate and manipulate these stories from their teams into hub pages (so-called “channels”) for display on the site using a separate interface. There were also interfaces for the editing of video metadata and specialist tasks such as the maintenance of the iconic MailOnline “side bar” (or “puffs” as they were known internally).

Starting the project

As the sole UX designer on the project, I sat with a group of five to eight engineers from the start. I initially established myself as the ambassador to the editorial teams while the engineers worked on their approach to the technical architecture. My role from then on was to discover how reporters and their editors were working and what they needed. This involved:

• Creating a rich prototype to envisage the future of the final application.
• Maintaining tight feedback loops with users – encouraging engineers to accompany me on travels through the editorial floor.
• Working with the Managing Editor to organise more formal beta testing of the resulting technical builds.

Design principles

It was important from the beginning to clarify what the UX needed to concentrate on. With such a large project, we could be swamped with feature requests we couldn’t prioritise.

Over a couple of weeks of observation, I established a number of design principles against which features could be judged, prioritised and argued effectively.  There were 16 main principles (divided between business logic and interaction), some examples of which were:

Speed over accuracy: MOL is about blasting out content better and faster than the competition. When in doubt, the system should aim for speed and efficiency over the aesthetics of the final layout, fit to display device, etc. Those are secondary considerations.

Go from the general to the specific: To support Principle 1, the system should allow the creation of objects first in an approximate state, and then provide refinements and enhancements later (eg cropping a picture is optional; adding video metadata can wait).

Simplify the model: Give the user a simple model of clearly defined “objects” to deal with. Have no more than three of such objects: content (articles, images, videos), content modules (carousels, link lists, etc.) and screen furniture (“fact boxes”, pull-quotes, divider lines etc.).

Start fast: A new user should be functionally literate in their role using the system in under 60 seconds.

One thing that became clear early one was the problem of lost work. All other usability and process problems paled into insignificance compared to a reporter losing their work.

So I impressed upon the team the importance of undo and auto-save. We were to have no “save” button in the UI. This met with some resistance, but the principle (speed over accuracy), as opposed to the finer details of implementation, were hard to argue with.

I was also careful to establish an agreed baseline for publishing speed (the time, as recorded in the system logs, from a journalist taking a story from a news feed or other source to the point of it being published live).

Compromises and solutions

Although we had the ability to create a CMS from scratch, two main systems remained largely beyond our reach:

• The picture desk system (which gathered up to 7,000 photos a day and made them available for use in the paper), save for a simple API.
• The legal team’s copy editing tool: a large bottleneck in filing stories for the TV Showbiz desk in particular (who had to have legal clearance for all stories they published).

Overcoming these issues was again a case of understanding the details of the problem through ethnographic research. Once I had those, we arrived at a compromise that was at least some improvement, and specified a future solution to keep “on the shelf” should the opportunity to replace the relevant systems arose.

This “solve now, implement later” (sometimes needing revision in the light of later events) was an important tool for us going forward. It helped us form a vision for the product and informed the features we were implementing at any one time.

A UX takeaway

Over such a long project, we inevitably learned many things about ourselves, our systems and the organisation.

From the realisation that individual journalists have quite different approaches to writing stories (so making small user research samples harder to rely on), to the effects of “programmer anarchy” on the design process – when everyone can be a designer, designers need to justify their salaries!

Perhaps the main lesson from this was that time is the UX designer’s greatest advantage. The time to think about the right solution rather than just any solution.

☙

Launching and further iteration

I chose a group of 50 reporters as a representative cross-section of the editorial teams to whom we could gradually release each revision a few days before turning it over to the whole organisation. This also became a form of user testing, often immediately incorporating feedback I observed from discussions with members of my test group.

As we reached feature parity with the old system and beyond, we saw we had increased the speed of publication by 30%. against our initial benchmark derived from the timestamps between article creation and publication, as recorded in the system logs.

 

A prototype I built to demonstrate concepts for an evolution of the main article editor.

Overall, from the feedback we received from journalists and editors, we achieved our primary UX goal for this new CMS: to make it easier and quicker for them to learn and use.

Investing in the UX of internal systems design is important. It may even be as important to the long-term health of a digital business as their investment in customer-facing systems.