Everybody hates their content management system

We need to spend the same time and attention on our internal systems as we do on our external facing websites. Just look at your content management system.

I was sitting in a board room trying to discuss digital transformation. Unfortunately one person just wanted to talk about was how terrible their content management system was.

How come I can download an app onto my mobile and instantly know how to use it, yet have to go on a training course to use our CMS? Shouldn’t a content management system be intuitive?

He was right of course. They had 1200 people across the organisation, the majority of whom were struggling to use the CMS. All that frustration! All those wasted hours!

He wanted the organisation to switch content management systems. I pointed out that most had the same problem and that this was treating the symptom and not the underlying issue.

I have worked with many content management systems over the years and in every case people complained about them. Are they all terrible? Or is something else going on?

I believe that the problem lies in how content management systems are sold and then used within organisations.

Content management systems are mis-sold

This may date me, but I remember when content management systems arrived on the scene. Many saw them as the silver bullet for all their content issues. There was a perception that content management systems would allow anybody to update the website. This would do away with the need to expand the web team to support increased interest in digital.

This was and is a perception encouraged by content management system vendors. They sold their systems on the basis that anybody can now publish to the website.

In truth things are not that straightforward.

For a start most content management systems are not fit for that purpose. That is because content management system vendors overestimate the skills of the average user. The majority of content management systems are not easy to use. They contain far more functionality and complexity than the average user needs.

Furthermore, with this distributed model, most CMS users only update the website occasionally. This means they are not becoming familiar with how these systems work and forget any training they have received.

There is also an assumption that allowing large numbers of people to update the website is a good thing. I am coming to the conclusion this is not in fact the case.

Large number of editors has a dramatic impact on quality, consistency and relevance. Content contributors are not experts at writing for the web and rarely have the time to keep that content up-to-date. Even if they have the skills and time, without editorial control their will be no consistent tone of voice across the site.

You maybe left wondering what the role of a content management system should be. If they are too complex for the average user and too many users undermines quality, why have a CMS at all?

The truth is they do have a place, we just need to adapt our thinking about their use.

Changing our approach to content management systems

Content management systems are a tool for enabling digital professionals to manage online content. They are not for the ‘masses’. These are powerful, complex systems that allow a high degree of control. More control and functionality than should be in the hands of non-specialists. Admittedly, in an organisation with a high degree of digital expertise this might not be the case. But as a general principle I believe it stands.

Introduce a central editorial team

What organisations need is a central team that works with business specialists to write effective web copy. This team then posts content online using a CMS. You need that central team to ensure quality and to also maintain existing content. This includes removing content that is no longer relevant.

This will create a bottleneck in content production, but I would argue that is a good thing. Content management systems encourage anybody to put content online. This makes it harder for users to find the information they want. Too many of our sites are full of content ‘that somebody might find useful’ rather than focusing on specific use cases.

This is a lesson being learnt by the European Commission. As part of their digital transformation project they have removed 90% of their content. Content that proliferated because of wide spread access to the CMS.

There are of course exceptions. Updating staff profiles is something better done by the staff themselves. Updating content such as news or job postings also sit better with those who produce the content. But that does not mean these users need access to the full blown content management system.

Even with limited permissions, many users find content management systems far from intuitive. Training is not an option because people forget, forcing refresher courses. This ends up being expensive and time consuming.

Build custom interfaces for common tasks

Instead we should be designing custom interfaces for the content management system. Interfaces tailored to the workflow users are trying to complete. In other words instead of having a single interface for the CMS, there should be different ones for key tasks. Tasks such as updating profiles or adding news stories. The digital team would continue to use the normal CMS. The customised interfaces would be for employees trying to complete a small group of specific tasks.

The huge advantage this brings is that we can tailor these interfaces to the way people already work. We will not need the user to adapt to the technology.

Most enterprise level content management systems enable this kind of customisation. Unfortunately, organisations are unwilling to pay for it. This makes little sense.

The cost of CMS training and the hours wasted struggling with the CMS would cover the price of designing a tailored interface. In fact this approach would likely provide a return on investment in productivity savings.

Custom interfaces for specific workflows and a central team dedicated to ensuring quality will transform your CMS. It will go from a hated necessity to the powerhouse that drives your website.

  • I think web shops should take more care to address the concerns of website visitors and the website administrators. There are two different types of users and we often forget about the internal ones. This is a great article! Do you think that developers don’t use enough limitations to create templates so content is made more uniform? It really is all subjective and changes per client, but i think it is ok to have more content editors as long as you limit their permissions and set up a specific dashboard for each role so the path is laid out clearly.

  • Where I work, you really see and appreciate the contrast between the utility of the content management system versus the quality of the content creator. Our creators are experts in their fields–subject specialists, Ph.D’s, etc.–with a ton to say, but when the CMS is a pain in the ass to use they would just rather not say it. For me, I was surprised after spending so long with WordPress how *foreign* and *weird* and *not user friendly* the WordPress dashboard is to someone who has never seen it. I ended up removing the entire WYSIWYG and replacing almost everything with custom fields, each with optional instructions, so that the pace of content creation is step-by-step.

    I found that when even the best content makers are presented with a blank-slate WYSIWYG, they stall.

  • Bauhem

    Excellent article! I’m currently using CloudCannon as CMS for my client. They love it because they can edit text and image directly in the design, and also, they can duplicate things really quikly. Some features are missing, like creating pages, but this is perfect for my clients needs.

  • I think that as web designers/developers, we often create this problem ourselves. We’re too quick to start talking about how great a certain CMS is, how easy it is to use and how the client will be able to edit just about everything. The problem with this is that giving a client full control is usually a really bad idea and often clients find a CMS much harder to use than you first thought. They’ll quickly break the conventions, the structure and the flow of the content that you worked so hard to design. I’ve seen this first hand, clients destroying a perfectly good website as they attempt to cram more content, images, PDFs anywhere that the CMS will let them. The client is trying to do the right thing but they don’t have the expertise or design capability to do what they want to positively improve their website. They then get frustrated at you and the CMS because it’s not allowing to do exactly what they want and for it to look great.

    We definitely have to take a different approach to the way we offer/roll out content management systems. Clients need to understand that there is no one size fits all solution and that sometimes the best thing for their business is a custom offering. Yes, this might cost them more money in the short term but as Paul mentions above, in the long term not having this custom solution could become far more costly to the client. Clients also have to appreciate that there is a lot that goes into creating content online, so we can’t just provide them with the tools to create content if they don’t understand the principles behind creating great online content.

    I think the main point is that it’s on us to educate our client effectively. Most of the time they want to do the right thing, they want control so that they can add value to their websites. We have to stop telling them there is a silver bullet solution and put in the additional effort to educate clients about what will work best for their business. Then maybe our clients will start to love their CMS!

  • The question here is: Why do organizations use complex content management systems for large user bases at all, e.g. for their intranet platform? When it comes to collaborative content creation, and getting subject matter experts and all other types of employees involved into the intranet or knowledge bases, an enterprise wiki like Atlassian Confluence might be the better choice.

    Confluence has an intuitive interface and a graphical editor that everyone can handle who knows some word processing basics. From my experience as a content consultant, users that are new to Confluence are happy to finally find a system where they can focus on the content, and don’t need much training to get started.

    Another point that makes Confluence attractive to many organizations is its extensibility via add-ons from the Atlassian Marketplace. And for all the content professionals who want to manage content efficiently, there are add-ons available to provide advanced content re-use, concurrent versioning, multilingual content, review workflows etc. It’s also easy to bring Confluence into the corporate style using themes or add-ons like Scroll Viewport from the Atlassian Marketplace.

    So instead of building additional user interfaces for casual users or limiting access to authoring-proficient editors, many organizations will benefit if they start walking the ‘wiki way’, crowd-source their corporate knowledge and get everyone involved in the content creation process.

  • Ross Johnson

    I agree completely, but also think management of expectations is part of the problem. If the client doesn’t understand that a CMS is there to manage content and not to design webpages they often struggle trying to do something a CMS was never intended to do (custom layouts, etc…) I’ve had several conversations with frustrated clients who expected their CMS to behave like PowerPoint. Had we discussed the need to have *designers* create layouts and frameworks that the editors could then populate we probably would have avoided the issue.

    Simplified interfaces for specific tasks would no doubt improve things, but I wonder if you’d still run into issues where an editor wants to “move this thing over there.”

    • We try not to provide a WYSIWYG editor at all, or if we do, then disable as many buttons as we can, and only provide a small set. Do NOT provide ALL the WYSIWYG buttons in the editor! Bye bye nice design, hello massive red bold font to emphasise a Sale item or something! So the customer either just cannot create any layouts whatsoever (so they can only change “Blog Title”, “Blog Image”, “Blog Summary (textarea only)” fields, or if they do have a WYSIWYG, then they can only use Bold, Italic, Font Formats (H1, etc), Link, Image and a few others. There are no tables, no DIV buttons, nothing to allow them to start trying to create their own layouts.

      So basically the CMS is to manage content, and not to manage design.

      Then sometimes we have a customer say something along the lines of, “I’m trying to create two columns for my content but cant see where”, in which case we explain that layouts are not controlled in the CMS, we would need to build that layout for them.. if its something they will use often and want the choice, we could offer a choice of layouts in the CMS (maybe a dropdown), so they can select which one. They dont build it themselves.

      Saying all that, we do sometimes just add in a Table button but always add a disclaimer that “we are not responsible for final design of the content page if you start messing with layouts” or to that effect!

      • I understand this approach, but on the other hand when everything is locked down, this can be incredibly frustrating for a competent website manager. The layouts would have to be 100% bullet proof and extremely well designed, which isn’t always the case.

        The ideal solution is a flexible CMS (Drupal or WordPress for me) managed by a skilled content manager!

        • Yeah if they are competent then give them a WYSIWYG or something. Locking it down would be for those who are not very competent at website content management, which in our case is a lot of our customers as their expertise lies with their core business activity and not website management!

          The ideal solution you mention may not be suitable for all cases, everyone is different and there is no one CMS that suits everyone. Its not our ideal solution to be honest :)

  • Linda Mitchell

    Irrespespective of the relative merits of a CMS and how easy it is to use the distributive authorship model for mantaining web content will fail unless properly managaged with ongoing user training, and support and vigourous moderation processes. However, writing for the web is a specialist area and should be left to those with the skills and knowledge to produce consistent, quality, user firendly and acccessibile copy. Authorship should be limited to small team responsile for writing and maintaining specific aspects of a site such as new and events listings, employment oportunities, blogs and message boards and page content.

  • A spot on article!

    Based on my experience it’s always preferable to have a few people responsible for managing a sites content rather than many. That way the small team can become proficient with the right training, rather than dealing with many folks who aren’t really up to the task anyway, and never will be. At the end of the day getting 4 or five people up to scratch is a lot easier than 20 or 30!

    What I have found with the CMS I specialise in is that it’s very easy for most people to pick up. I can tailor everything from content input to access levels, and remove all distractions or areas that the logged in user doesn’t need. More often than not an hours training is more than ample for most people, and after that support requests are few and far between. This is from a well known commercial CMS that has an affordable licence fee.

    As you rightly suggest choosing the right tool for the job is half the battle, unfortunately it’s all too common these days for people to just “throw WordPress at it” without considering the content, users and general suitability for the task. While WordPress has it’s strengths it can be (and often is) part of the problem – that’s probably why a lot of my work involves migrating sites away to more suitable platforms that clients find easier to use. Note this isn’t bashing WP, just how I see things every day.

  • Colin James Firth

    I totally agree that content should be managed by a central team rather than distributed. It’s the only way to effectively manage quality and consistency. But even then, for content managers, most CMS systems are far more complicated than necessary – or at least appear to be because of poor UI. Unfortunately, because the CMS isn’t customer facing, it can often be hard to sell a good system to clients where costs are an issue. Which is probably why CMS’s have lagged behind in the race for better user interfaces – and look poor compared to even modest examples of modern consumer-facing software. There’s certainly work to be done, and as the focus on quality content continues to increase, it’s something that’s likely to become more important.

  • Use a CMS that allows customisation of the admin to tailor the feature set and workflow to the customers needs. Do not use a CMS out of the box with so many features that the customer only needs 5%.

    The problem is too many web designers doing the latter and not the former (probably because it’s easier and cheaper for them).

    • Definitely agree that some designers/developers are taking the easy option, using things out of the box because it’s quicker and maybe more profitable for them. I do also think though that as Paul mentions above, many designers/developers are so familiar with there CMS offering they sometimes just don’t realise it might not be as usable for their clients as they think.

  • While I agree that (though mostly in the past) “content management system vendors overestimate the skills of the average user”, I don’t find it neccesarily true that “They are not for the ‘masses’”.

    Having spent a very long time on designing a scalable UI for the open source TYPO3 Neos CMS in order to handle very different degrees of complexity, I’ve also—through a bunch of research—seen other CMS’s moving towards this goal of being usable for both highly skilled editorial teams and the occassional user. Quite naturally so, as most vendors or communities building CMS’s don’t want to drop user segments.

    You kinda give the answer to this particular UX challenge yourself when writing that “instead of having a single interface for the CMS, there should be different ones for key tasks”.

    A year ago, I wrote that “Editing something can – and should be – done in different ways for different purposes” (http://rasmusskjoldan.com/post/58364140673/wysiftw). Now, we’ve tried this concept out in real-life with the Neos project during the past year and it works as it should. It’s fairly difficult and complex to plan custom interfaces to match different needs but it’s not impossible to bridge that gap.

    Thanks for a nice article.

  • G H

    My new boss asked me about getting a content management system. I told him that we needed a “Task Management System”. When he had no clue what a task was, I knew I was dealing with someone who didn’t understand web.

  • Will Pittinos

    This might be the first time I’ve read one of your blog posts and thought, “Paul, that’s not exactly right.” I’ve worked with a CMS that, truly, anyone could use. We’re too willing to accept that a CMS should be a difficult thing to use, at least in higher ed. Here’s an example of an extremely powerful system that allows developers freedom to do their thing and allows basic users to help make site updates: http://livewhale.com/. There must be more out there, right? Of course, this does require some training about how to create web-friendly content. But a, dare I say, fun CMS might also make users willing to spend some time learning how to create that great content.

    • Hi Will.

      So I have just watched Live Whales demo. It seems to me they are doing exactly what I was proposing. Opening a limited amount of functionality to anybody and then keeping the rest for experts. Am I missing something?

      • Will Pittinos

        Hi Paul,

        Absolutely, I think you’re suggestions are very similar ideas to what’s available in LiveWhale. Those limited editors, though, shouldn’t despise making those changes. An ideal CMS would also make them want to learn how to do some of the more expert tasks (and that should be easy to do in the CMS). I’ve seen someone who never edited a web page tackle tagging and then creating customized feeds of content that use those tags. It’s certainly not complicated web development, but I think we should challenge CMS’s to make themselves that easy to use. Too often, I think, negative experiences making simple page edits turn off potential site contributors who have content that communications offices might not otherwise discover. And that sometimes creates an impression that it’s a “bad website.”

  • zvineyard

    Hi Paul, great post here. I’m using PyroCMS (and its streams module) to solve problems you address in the ways you recommend. Instead of offering users a WYSIWYG to enter something like a job posting or a piece of news, they see 1 form dedicated to adding that content to the site. Then I can say this to a content editor: “Fill out this form to add a post to the site,” or “Fill out this form to add an article to your blog.” These forms may or may not include WYSIWYGs.

    The layout issues are still a problem, so we created 2 ways of handling layouts. For admins using the system every day, they can just tap into the power of the grid system (960 or 1140) by stacking each piece of content into the grid. For editors, we build custom layouts. They can choose the layout when creating a new page.

    I’m not sure large sites can survive being spread across a large group of content editors. I think building a centralized content editor team (and a bottle-neck) is workable, especially if you want quality, updated content.

  • In your opinion, what defines an “enterprise level content management system”?

    • The lines are much more blurred than they were. I guess I consider a CMS that supports complex permissions and workflows as being an enterprise system.

  • Hello Paul, I agree with you that “most CMS user update their website occasionally”. I’m currently using WF5 as CMS for my website. I find it very easy, flexible framework to customize, and admin friendly. That’s why I don’t have any regrets in using this kind of CMS. And also I always update my CMS regularly so that I can get access to the new features. Thank you..

  • This is Great Wonderful Information.. useful ideas thanks for sharing..

    CMS Development Services India

  • WouterCox

    A mobile app usually has very limited features compared to a full-fledged Content Management System. But I do understand where that user is coming from!

    I have seen and used quite a number of CMS systems in my 13-year career as a web manager, both commercial and open source.

    The problems that I personally see:

    * too much features and complexity,

    * the myth of the out-of-the-box CMS,

    * lack of tools to actually manage content,

    # Too much features and complexity

    Companies in the process of buying a CMS usually demand too much of it. They have unrealistic expectations of it and usually want everything **and **the kitchen sink. Unfortunately, more features means more complexity. And most CMS systems do a poor job of hiding this complexity for the user. More features usually also means the system is more susceptible to bugs. It is a bit ironic that after a website launches, CMS editors are usually complaining features x, y and z aren’t there even though they *know *they were in that other CMS system they once saw or used.

    # The myth of the out-of-the-box CMS

    Every company has its own way of working. A Content Management System should **adapt **to this way of working, rather than **twist** the current way of working in such a way that it will work with the Cms.

    This is one of the reasons why I love CMS ‘frameworks’ where you can strip or extend the Cms as much as you need. I am most familiar with MODX myself, but there are others as well. Let’s say you want a blog that works just like the blog you used to have. With a framework, you can program it that way. With an ‘out of the box’ solution, you have to work with what’s provided. You can also strip everything you don’t need to improve performance and hide every interface element editors don’t need to ensure the system is easy to use and the company style is respected.

    # Managing of content

    In theory, anybody can publish content. But not everyone **should**. Publishing content requires certain skills that some people just don’t have and often aren’t interested to learn.

    As for CMS systems, they often lack the very tools needed to put high-quality content online:

    * sane workflows,

    * inline spell-checking,

    * easy access to the style guide from within the editor,

    * an easy way for site managers to see incoming content, to see what is changed and give feedback to editors,

    * tools to check and act on outdated content.

    It is therefore not surprising that more and more companies are relying on tools that **do **a good job managing content, such as Gathercontent. Gathercontent is a great tool, however with most CMS systems there isn’t a reason why such functionality can’t be provided within the CMS proper.

    # The current scenario and the ideal scenario

    Exactly like you wrote, a distributed model can often be detrimental to quality. I have worked with the distributed model for a long time, and what you say about training and quality rings eerily true.

    ## How it usually goes

    * A large number of people gets training to use the Cms and to write for the web,

    * forget the rules,

    * don’t have (get) sufficient time to actually **manage** their content,

    * lots of requests for support, for example they forget basic things such as how to log in,

    * don’t have easy access to the style guide’s rules,

    * the extensive functionality in Cms systems makes it harder to use it, makes the system more error-prone and frustrates users when functionality they want isn’t there.

    ## How it should go

    * There’s a plan for how the content will be managed **before **a CMS is implemented – or even chosen.

    * A core team (limited number of people) gets installed

    * They get CMS training and web copywriting training.

    * They handle approval and basic technical support questions.

    * Editor(s)-in chief / Admins, they handle:

    * content planning and content governance,

    * more advanced support questions,

    * bug reports,

    * feature requests.

    * Editors use a custom interface or an external tool such as Gathercontent

    * style guide and spelling guide always within easy reach, ideally accessible from the editor,

    * only the fields that are needed for the current task.