Back-end designs and the CMS cycle of disillusionment
Added By Adriaan Bloem at 27-Aug-2009 | Twitter: @adriaanbloem |
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.
Next steps: Get a free research sample or purchase complete vendor evaluations to obtain immediate access.
Categories: Adriaan Bloem, Web Content Management
