Over the years, I’ve seen a large number of web site functional designs, technical designs, requirements, wireframes and mock-ups. But usually, the one thing missing from the planning of a WCM-driven web site is what’s most likely to shoot the implementation in the foot: the functional design of the CMS back-end. The form & function of how the CMS will work, look and feel for the end-user of the system, not the visitor to the web site, is too often overlooked.
This is odd: isn’t the rationale for getting a CMS in the first place usually based on some kind of ROI in efficiency in actually producing the content and sites? This is where editors, authors, webmasters and content masters are spending their nine-to-five. Shouldn’t this environment, the UI they’re working in, be completely optimized to make their task as easy and as comfortable as possible? Shouldn’t the CMS be a tool that supports the content management process?
Yes. However, an all-too-common scenario is as follows: a new CMS is procured, the implementation takes about a year to settle down, and the next two years are working up to replacing it again. The official business case for the replacement, of course, will be the brand new site that’s going to be built. And it’s tacitly accepted that a new site will require a new infrastructure, so that’ll be budgeted for. Around that time, editors and webmasters will start to become slightly more vocal about their concerns with the current CMS (since the site is being replaced, why not chuck out the old CMS, as well — after all, it never really functioned all that well, right?). The current CMS is therefore chucked out during the process.
The new site, being built on a brand new CMS, will be based on visitor-facing, front-end wireframes and designs. It’ll get some highlights to work from (for instance, user-generated content is a particularly hot requirement for websites right now), followed by functional designs and technical designs of how to deliver all of this to the visitors. That’s what’s going to be built by the developers.
All too often, the developers will make things work for the site — without much concern for the editors, since that was never defined. Many simple, straightforward, reproducible tasks will take insubordinate amounts of work. For instance, there are plenty of implementations where publishing a news story will take more than thirty steps to complete and go live. Sure, it works — but is it workable?
The users will, almost without exception, blame this on the CMS (not the implementation). And they won’t just dislike it, no, they will often loathe their system. (Talking about a particularly bad implementation, I’ve actually seen web editors break out in tears.) The really strange part is that I regularly see customers switch from CMS A to B because they hate A, while others are switching from B to A because they hate B. That often just means trading one set of problems for another.
And that’s how the cycle of disillusionment comes full circle — in three years, it’s time for a new system. The vexing thing about this: usually, it wouldn’t have been neccessary. The CMS may or may not be a bad match, but often, it’s just never really made to fit. All the effort that went into persona development and UI design for the web site, should have also been undertaken for the WCMS.
Of course, I’m cynically exaggerating here (though really not by much). Is it possible to select a CMS that won’t be the bane of your user’s existence? Of course it is, if you very consciously decide on trade-offs between what you want a site to do, and how easy this should be for your editors to achieve. Don’t just pay attention to what visitors will be getting; spend time on understanding on how your WCM system users are going to actually manage the content that’s served.
Again, a CMS is just a content management system, and it’s there to support a content management process. The system should be there to mediate between the back-office and website. Pick one that allows you to resolve these conflicting interests for your scenarios, and design this back to front.
Of course, producing the site is, in the end, what it’s all about, and for your WCM system users, it’s their job to do this. But lest you ever forget: you really don’t want to make your editors cry.
This post was previously published on the blog of my former employer, the Real Story Group, an industry analyst firm specializing in vendor neutral reviews and advice.
You posted a link to this as an answer on Quora and I upvoted, but I wanted to thank you here as well. I think this is absolutely accurate. A lot of time and effort goes into the end-user experience, but very little into considering the workflow of the content managers & editors.
This is a real mistake because the experience of the web site depends heavily on the content managers following the conventions UX and designers have established. If they can’t (or won’t) do it, the vision of the web site won’t survive much past launch.
Thanks for the comment, and the upvote John 🙂
Almost four years after writing this post, I’m still surprised by how we’re still underestimating how hard managing content really is (especially at scale). And there’s still a serious lack of understanding that managing content is not the same thing as managing a website (and you need both). WordPress, Drupal et al. have made this worse: now, everybody thinks a CMS is what your site runs on. The interfaces are getting better, but the “managing content” part of it is more of an afterthought than ever…