Stop letting people use your CMS

Seth Gottlieb at Content Here is on a roll lately with some great thinking.

His post on The Myth of the Occasional CMS User was timely based on some conversations we’ve been having around the office. There is a lot to unpack in it, and of course anything with Myth in the title catches our attention.

Seth summarizes a frequent pain point with CMS rollouts:

“Often, one of the big justifications for a CMS is removing the webmaster bottleneck and delegating content entry to the people who have the information. The implicit assumption is that everyone wants to directly maintain their portion of the website but technology is standing in the way”

He goes onto explain all the reasons why this can wreak havoc and have people assigning blame to the wrong areas. He correctly points out that CMS failure often comes down to expectation setting, a topic we’ve covered here on the Myth as well.

I can’t tell you how many times we’ve seen organizations buy a CMS, take their same content structure, and simply distribute authoring ownership to every far flung corner of the organization. And let’s not entirely blame the organizations. It’s how CMS is sold. And it’s a myth, straight up.

Here’s a familiar scene.

You have dozens of users in CMS tool 101 training sessions with no idea why they are there, no familiarity with the publishing model and no incentive to learn how to keep their piece of content up to date which rarely needs to be updated anyway. This never ends well.

And the CMS technology itself only magnifies this problem. Content management systems do a lot of things well, but they are not built for the occasional user. Far from it.

They typically expose all the functionality you need to build pages and sites, but they are not organized around supporting task-based content entry. And occasional users have very specific tasks.

I know vendors will disagree, highlighting things like inline editing, roles based security and workflow. But in almost all cases, it still doesn’t work for the occasional user. The pain far outweighs the gain.

So, I’ll take it one step further than Seth. Stop letting people use your CMS unless they are an integrated part of your web and editorial team and need to be in it on a regular basis. Even then, they may not need to be in the tool.

Seriously, don’t let them in. Even if they beg.

Build other processes for allowing them to request updates and get content into the system. Lie if you have to (sorry, all out of seats!).

Your content publishing process should be oriented to serving your site visitors (content consumers) not the internal structure of your company.

Build an editorial process and team that supports getting this content published in the most effective way possible and stop forcing administrative assistants to sit through tools training.

Everyone will be better off.

About the Author
Jeff Cram

Jeff Cram is Chief Strategy Officer and co-founder of Connective DX (formerly ISITE Design), a digital agency based in Portland, OR and Boston, MA. As the Managing Editor of the CMS Myth, Jeff is passionate about all topics related to content management, digital strategy and experience design.

More articles from Jeff Cram


10 responses… read them below or add one.

  1. Andy says:

    We are currently in the process of acquiring and new CMS and are struggling with this exact problem. Over 300 users and very few have the right skills to use a more complex tool that gives them ability to do more with their site. I agree – have fewer “power” users that can really take the potential of some of these new CMS tools and make great sites with quality content. Power users can do it better, faster and give your site a user experience that makes people want to use the site versus the occasional user that hacks up quality into a crappy user experience.

  2. Rick Cabral says:

    A bold statement to be sure, but one that rings true. I’ve found during CMS user training sessions, many casual users vote themselves off the island early in the day, leaving the “power users”, who typically are either offline approvers, or marcom CMS owners.

  3. I totally agree. Even though we’ve spent a great deal of time investing in the usability of our web CMS (Amaxus), it’s almost an impossible task to cater for the ‘occasional user’.

    You can see this in the number of supposedly ‘very simple’ web publishing platforms: WordPress, or even Tumblr. These may think they are catering to the ‘every man’ (or woman), but I bet the majority of people (who are not familiar with the web publishing metaphors of process in the slightest) will still have little understanding of what they need to do. Even the humble WYSIWYG is confusing to most users, no matter what we might think or hope.

  4. I suspected there would be these sorts of issues when it comes to CMS — you know what they say, too many hands in the soup can really spoil it for everyone. But coming from a web designer/developer perspective, I’m trying to get my head around Joomla!, an open source CMS and it’s not them most intuitive interface as they tout and I already know a fair amount when it comes to development. After putting time and energy into creating a CMS site, I would want to know that after I hand the website off to the client, they guard the gate and allow an assigned few who know what they are doing generate valuable content for their site visitors.

  5. Colette says:

    Great article. It is so true. I am running 8 websites for a state government in Joomla that Kristin mentioned above. I love the product, and actually find the interface very user friendly, but I use it every day! In the past, we have let staff in some of our divisions have a small hand in some HTML pages (our old site) and the biggest problem I have in training, is they can’t let go of HTML. It’s next to impossible for some of them to understand that a link on the page is just pulling a query out of the database. They participate very little in updating (once a month or so) and retraining or “reexplaining” is time consuming. I wear all of the “web hats” in the agency so having a little help is important. We are finally hiring a new staff (starting tomorrow) and hope to pull the reins in a bit on “outsourcing” our jobs.

    Great article. I wish all web developers could read this prior to the start of outsourcing the content management.

  6. “Build other processes for allowing them to request updates and get content into the system”

    Yeah! Good idea… you could build a system to help with that! Maybe a web based system… users could enter content… and it could y’know… manage the content…

    oh. wait.

    My bad.

    On a serious point though. You (and Seth) have a great point here, and something we have seen many times before on CMS deployments (along with the other great chestnut: rip-out-the-workflow-at-the-11th-hour-cos-the-reviewer-has-gone-on-holiday-and-we-launch-tomorrow).

    Whilst you really don’t want just *anybody* entering content in, there is a halfway house: most organisations have some distributed admin roles (think departmental secretaries) who are ideal for this. They are generally organised, they are generally the one who gets something thrown onto their desk to ‘send to the web team’ or ‘file’. Just one thing to bear in mind with distributed authoring is you have just gone and given someone yet another thing to do. Beforehand they just emailed it to someone else and it was no longer their problem. Now *they* have to actually type it up and edit it etc. Some people don’t like that.


  7. If you have dozens in a room and no idea why they are there then is training flawed? if occasional users have their access taken away they will be less likely to add content. Content is King in the online world, right? A year ago I relaunched a website and launched a new marketing plan which involved having people blog. They need access to the blog to post their articles. Some were not given access and told to email their blog posts to me. It turned out that those with access to the CMS blogged more. I recently worked on contract for one of France’s best business schools, and I was asked to make updates constantly because in this case we were suffering from a TERRIBLE implementation of ezPublish (which turned out to be a very contradictory name). People were annoyed when their updates were not done right away. I trained people to make they kind of updates they needed – then they were fine. The bloggers at the other company were trained specifically on what they needed to be trained on. I think often times the training is flawed because people are over-trained and over-whelmed. Taking away their access all together will lessen their likelihood to contribute content and today marketers need the experts in their company to create expert content. In addition I think it helps to allow contributors to preview the content to make changes etc before making it live. I also think that occasional users need a few attempts to feel comfortable using the CMS and yet they hang on to the overwhelmed/over-trained feeling (which is why most don’t like doing it) and that’s when they become a statistic: a non-contributor! That’s my perspective as a marketing professional. Here’s a more technical perspective from Oshyn .

  8. Andrew Odri says:

    A little disclaimer upfront: I am a developer at Konductor—and yeah, we make CMS. A bunch of us at Konductor had been working with CMS (and selling it) for a long time, and we all noticed pretty similar trend as well—setting up a CMS wastes designers time, learning and using CMS wastes users time (and often the designers, because when it is too difficult to do something they call you up), and many times it takes some custom development.

    Although rather than telling clients to abandon CMS, we decided to create a tool customized for each user group: a Dreamweaver extension for designers and backend system that natively accept *.dwt’s, so that can upload anything they want without need custom markup; and a standalone AIR application for users that is really simple to use, but maybe not with all the bells and whistles.

    The cool about this is that the designer can set what regions are editable, and define the CSS that gets applied within the region. They choose to expose extra CSS classes for the user if they want to. And they can lock down what can be inserted into the region. This way the designer can essentially set how much the client is allowed to change, and define how that looks, so that you avoid have clients turn the design into a train wreck.

    Anyways, it’s prolly worth a look—we have a some good tutorial / overview videos on our YouTube channel, might give you a different perspective on what CMS really should be like.

  9. Steve Brown says:

    I hear you.

    We have a VERY large website and have in place what I would consider a “better than average” distributed publishing network. We have always asked for a “small, precision driving team” of contributors rather than a “mass of sunday drivers”. We’ve never got it.

    However, one of the things that we have done which I think really worked well is have 2 levels of training. Basic training is self-directed (we have videos and doco to help) and then the user has to do a competency test. Basic training means you can ONLY update content – you cant add or remove anything. This means you dont need to learn about all those metadata fields nor do you need to learn about the best solution or approach to a prob – thats already been determined. You’d be surprised by the number of people who when offered either basic or advanced training decide that basic training is enough.

  10. James says:

    If you’re going to do distributed authorship with a gaggle of occasional contributors, then you need a CMS that works well for that. You need a system with very little cognitive overhead to get started. That means it needs to be similar to something your contributors already know how to use. For us that meant as close to a “shared folder on a file server” as we could get, while still being able to build an actual website.

    We ended up selecting Plone, largely because of the way it structures content into folders/pages. It’s hard to over-emphasize just how important this mental model is to getting contributors up and running quickly. Everything else we looked at required training just to teach contributors how their content was structured, let alone how to do anything with it.

    We give our “site owners” a small training packet and a 1-2 hour orientation. Most of them pick up the basics in 15 minutes, and we spend the rest of the time getting them started on building their content. Some of our heavier users have started training other people to manage subsections of their sites, and we have a number of sections that are so narrowly scoped that on-screen instructions are sufficient for training. It’s been about four years since our first users went live, and we’re closing in on 1000 contributors.

    Another key for us was skipping workflow in the majority of cases. We assume that contributors have the authority to publish the content that they own (otherwise they’d be giving it to someone else to publish). Because of the folder structure in the system, we’re able to grant contributor rights with a high degree of granularity. That makes it easy to keep department training events off the main organizational calendar, for instance.

    This was actually our fourth CMS implementation. The first two mostly worked, but adoption was abysmal because of how hard the system were to understand and use. The third implementation was a smashing success, but that’s because it was little more than a web-based shared drive for posting links and Word documents. We outgrew that pretty quickly, and Plone has given us a much richer palette without scaring away our occasional contributors.

Leave a Reply to Kimberly - Oshyn, Inc
  1. Fields marked with * are required.
  2. We will not publish your email.