Case Study: Iterating on Publishing CMS Interfaces


The Problem

The Django CMS has many good qualities, but the user interface isn’t one of them; it’s cluttered and requires too many clicks for a single task, in addition to being notoriously difficult to modify. My co-worker’s tweet said it all:

Internal users often get short shrift, the thought being that they’re less important than external users.  But internal users are still users; wasting their with bad interfaces wastes the organization’s resources, and is a business problem. For three years, I iterated on how we might make better solutions for the editors, art team, and writers at the Tribune.

The Solution(s)

My approach evolved over the three years I worked on it. When I first arrived, CMS “user research” was limited to items in the tech backlog, a morale-depletingly long list of unorganized tasks. This was in great part because we had no dedicated UX folks, nor a user research strategy.

My first step in “fixing the CMS” happened in 2014, when we built a totally new site using the same base system. Rather than repeating what the main CMS did, I collected user stories from the editors, prioritized them, and deliberately designed the interface around them. Since one of the major problems was overcrowded interfaces, I sat with the editor of the new site, and we sketched an interface that would include only what they needed.


We also designed our own interface for the editor to quickly arrange the front page lineup (one of the most time-consuming tasks in the main interface).


That still left the original site. To attack this, I decided I needed to do a more structured user study. In 2015 was taking IDEOU’s “Insights to Innovation” course, so for my project, I interviewed users and arranged sessions for our tech team to observe how folks from both the editorial and art departments used the CMS.

As the course predicted, this was incredibly enlightening: we learned that to get around the buggy bulk photo upload, the art folks would deliberately press “upload” multiple times, and then just change the duplicate images. We also learned that the editors didn’t find the spell check adequate, and were frustrated by the inability to preview in mobile.

We’d just hired an excellent Django engineer, and due to a lot of work we’d done to remove technical obstacles, we were at least able to fix some of most egregious time-wasting pain points. We implemented buttons or links to get around the multi-click problem where possible, and added a mobile preview.

The ultimate solution, and the one favored more and more by the tech community, was to make the CMS “headless”, that is, to use it mainly as an API, and to build delightful interfaces on top of that API. For this reason, we implemented an API in early 2016.

The Result

I estimate that we saved our users as much at 20 hours a week, both by implementing new UI choices in the CMS admins, and by showing those who needed data how to use the new API interface directly. The editor of the new site (who was a long-time user of the original CMS) really enjoyed the new site’s interface, and the amount of thank you notes we received as we added small fixes to the main CMS spoke to our users’ satisfaction.