Why your CMS is awful, I: capability & experience

What’s more valuable: having the capability to do something you’re interested in, or the experience of doing it without an undue amount of frustration and delay?

Seems like an abstract question, but it’s important to ask when you’re creating or selecting a content management system (CMS) for the web.

Remember the last time you used a CMS. Now, let me describe what you saw: A list of slightly different kinds of things, almost identical in appearance. An awkward mechanism for attaching images or other media to your work, involving a weird modal screen with a half-dozen fields you always ignore. An unused scheme for accessing older revisions of content. A way to work with draft content, or publish to a staging service, that’s still a little confusing after all this time. A sidebar or footer telling you that things you don’t care about are out-of-date. Oh, and somewhere, a few taps in, a wee text area, festooned with a rich text editor (itself having a stripe of about 15 icons, of which you use two or three).


The CMS nightmare I’ve described is typical of a system trying to offer the most capabilities. These systems make several claims:

  • that you can do all kinds of useful, amazing stuff;
  • that you should come to the system having already decided exactly what to write, or publish (and you’d love to type it all out into that tiny text area); and
  • that if you don’t know or remember how to use the system, it’s your own fault.

But they fail to acknowledge some important things:

  • that you, like everyone else, are stressed out by writing;
  • you’re worried about getting things to look and behave right, or that you’ll do something that undermines your message;
  • that you might have preferred to do this work from your phone or tablet; and
  • that you’d like the system to be smart enough give you reasonable defaults and let you choose only from options that make sense.

No wonder everybody hates their CMS. No wonder there are so many elaborate CMSes that go unused.


When someone, we’ll call him Joe, is motivated to go create or maintain something that requires him to go into the CMS, he’s already set about a very difficult task. Communicating with others is hard. Delivering a message is hard. Writing is hard. Encouraging readers to take some action is hard. Dealing with deviant and spammy commenters is hard. Writing a support entry about how to fix or replace a faulty hose that keeps falling out of the device is hard.

Therefore, setting about his task, Joe logs into the CMS. What does he see? A list of similar but slightly different things. A confusing sidebar. A wee text area.

Nothing here is providing a welcoming environment for Joe to do his work. There’s too much stuff, some of it never needed, most of it not needed right now. And if he completes the task that brought him into the CMS, he’ll feel that he’s succeeded despite the system, not because of it.

Which brings us back to the original question. What do people value more in a CMS: the capabilities they offer, or the experience they provide? For me, the answer’s simple. People value experience, and take capabilities for granted.

Having it all

Most open source CMSes offer a terrible experience, though they may be quite capable. They’re engineered from a one-fits-many perspective, with user interfaces that inflate or deflate based on which feature sets you’ve enabled. Introduce the dreaded plugin architecture, where little bundles of third-party functionality can be added (each dragging along their own user interfaces) and — well, you know where we end up.

Tremendous capability, hidden inside a poor experience.

For example, my favorite system for new content management projects is the Django CMS. It has a nice set of capabilities, a moderate amount of third-party applications that can extend those capabilities in the usual ways, and is otherwise easy to customize and improve. But, guess what? It’s just awful to use. The good news is that rounding off rough edges and improving a user’s experience is orders of magnitude easier than developing a modern CMS’s capabilities from scratch.

See the next post in this series for specific things a CMS should do to make it a decent environment to work in, as well as tactics for implementing those recommendations for projects that happen to incorporate the Django CMS.

“Why your CMS is awful, I: capability & experience” was originally published in the Different Chairs journal.