One of the most common complaints about digital publishing and content management is that “the editorial experience is terrible.” Sometimes that means ‘too slow,’ sometimes it means ‘not flexible enough,’ other times it means ‘overwhelming,’ and sometimes it’s just a feeling.
The interesting thing is that almost every organization I’ve worked with over the course of decades has said this. Most CMS users learn to live with the tool, but never come to love it; often it’s because few organizations put “front-end effort” into back-end tools.
About a decade or so ago @karenmcgrane and I did a talk specifically about this, leading with the idea that content creators, editors, and managers are users too; optimizing the backend experience for their work is as important as optimizing the checkout process for customers.
What we’ve found over the years, though, is that very few organizations actually understand the work their content creators and managers are doing in the CMS; that means that time and energy is often spent customizing and polishing the wrong things.
Almost a decade ago I had the privilege of working with the CNBC team as they planned a major replatforming — it was the first time I met an editorial team that uniformly LOVED their CMS and was ready to fight anybody who threatened to replace it. What made it so special?
My first glimpse of it was eye-popping. As in… the CMS was UGLY. Garish highlight colors, nothing but 1px black borders to call out different UX components, loads of text everywhere. And yet…
When asked, editors insisted that every bit of that clunky UI was doing something for them. The clunky sidebar wasn’t just links — it was a dynamic work bin they could add any data to, and keep with them as they moved from screen to screen.
The garish colors were ones they’d chosen — used to call out absolutely critical bits of information they couldn’t afford to miss when scanning huge archives.
And what had looked like “piles of boxes and fine print” on their dashboard was, on closer inspection, an editor-specific queue of commonly used queries. “I’m always pulling up stuff from the past year about companies Jim Cramer mentions; I can save that query and reuse it.”
Even more than the individual screens, the way the different editorial screens worked together was perfectly tailored to the daily and weekly cycles their newsroom navigated.
Their core CMS entities didn’t just capture public-facing content; they described the atomic elements editors used as starting points when assembling time-sensitive stories, or assembling new sections and landing pages. It encoded that particular newsroom’s working vocabulary.
They’d built their CMS on top of Drupal, and at the time it had a lot more backend flexibility than many of its competitors. But Drupal wasn’t why their CMS worked well. Their secret weapon was simpler: their key developers worked in the same newsroom the editors did.
They approached the CMS as a tool for their newsroom team, and that meant listening to them and watching them and working with those writers and editors to figure out not just what frustrated them but what they were trying to accomplish, under what circumstances.
Over the years it had evolved into a tool that wasn’t really screen-based or form-driven at all; instead it maintained a current “context” of assembled references, search queries, and in-progress articles that could be worked on with minimal context switching…
It wasn’t a developer’s idea of how to Structure Things Better or a designer’s idea of how to Make Things More intuitive. It was an editor’s vision of what they did all day.
There’s a lot to take from the story (and studying their system deeply shaped the way I approach projects for years after that). The most important is that there is no substitute for taking the time to understand how users do their work, not just how they use a feature.
Customizability is incredibly important for big CMS platforms. But the ability to customize doesn’t matter unless devs and developers (and vendors) understand the “flow” of the work, and have paths of communication with internal users BEYOND a queue of “feature/fix requests.”