Published on May 4th, 2010 | by Rahel Bailie6
Dispelling Myths about the Content Lifecycle
Until recently, descriptions of the content lifecycle were written up by technologists, usually content management consultants, who described the content lifecycle in the context of a CMS (content management system). This was apropos in one sense, as the one of the meanings of the word content means “being contained.” When content is seen in this way, it is but objects that are contained. Contained, inside of tag pairs that begin with <tag> and end with </tag>. And objects, as in BLOBs (Binary Large Objects) that get routed from place to place. The content types remain irrelevant, as long as they behave as BLOBs within the CMS transportation system. The content could be a graphic, a document, or fields of text that travel together.
This places the focus on the containers rather than that which is contained, which becomes more obvious in its context of description by technologists. The assumption is that forcing compliance of the containers imbues the contents of the containers with quality. The endeavour is considered successful when the system works as intended, and the contents delivered according to the rules written for the CMS. This is an upside-down view of content, where the tail wags the dog. It is time to dispel some of the most common myths around content and the content lifecycle.
Here are the first five content myths that came to mind.
Myth # 1: A content lifecycle must be tied to a CMS.
No, not at all. Content has a lifecycle, with or without a CMS; a lifecycle is an organic system. Before content was able to be managed in a technology-assisted way, the lifecycle was manual. Often, the lifecycle is still largely manual, and depends on human intervention to move the content from phase to phase. Organizations with large amounts of content have recognized that maintaining the content lifecycle manually is not cost-effective, and a CMS is the logical vehicle to corral and guide the content throughout its lifecycle.
Myth # 2: The success of a content lifecycle depends on the quality of the CMS.
Well, to an extent, but not really. It’s important that the CMS is able to support the content lifecycle, so having a CMS that is robust enough to meet the content needs is important. But having a quality CMS does not guarantee the success of content lifecycle. A CMS can only be programmed to support the process decisions made about the lifecycle. The success of the lifecycle depends on the content strategy that is formulated at the beginning of the lifecycle. If the strategy is flawed, then the content models, work flow, business rules and so on programmed into the CMS will reflect those flaws. So while the quality of the CMS is important, even the most sophisticated CMS cannot save a flawed strategy.
We only need look to the horror stories of the uber-CMS implementations of the early 00s to see how this played out in the past. The projects were all about the containers, and not the contents. The system sales were often made on the basis of features, and ill-suited to the content that needed to be processed. To use a metaphor, customers would ask for a vehicle to transport their content – a sedan, or a minivan, maybe – and be sold a ship, complete with the need for a harbour to dock it in, a crew to build it, and staff to maintain it. Analysis of the content and the content lifecycle would have illuminated the disconnects between the system and the requirements.
Myth # 3: Content can be produced independent of the user-centered design process.
You may rightly point out that content gets created independently of the user experience all the time. I would counter that this is why many websites are in the mess that they’re in today. The user experience professional designs for the process leading up to the content, but not the content itself. Common disconnects include designing spaces:
Too small to display the content in a way helpful to the user. This could result in a list of titles only, when having a content preview might be critical to a smooth user experience, or allowing for an arbitrary number of words or lines of text that results in a non-helpful half-sentence being displayed.
That inadvertently obscure or deprioritize the highest-value content. If content has not been taken through the UCD, it’s up to the designer to intuit what content type goes where. Some UX professionals do this better than others. However, in the spirit of “nature abhors a vacuum,” when design considerations lack research to back up where content types should be shown, that vacuum will be filled by other criteria – designing the content for attractive screen composition may not serve the needs of users.
That completely miss certain content types. Without a content inventory and analysis, the designer can lack certainty about the actual content types and their purposes. The content types could be grouped incorrectly, or presented in inappropriate ways – a whack of PDF attachments, for example, that really should be part of the copy on the site.
Myth #4: The organization doesn’t need governance to manage the content lifecycle.
The governance aspect is a critical success factor. In too many cases, a project has gone sideways or been abandoned because the chain of authority has not been explicitly set out, or because the processes have not been established and approved organization-wide. The governance model should be considered more of a web of determining process around your content operations. In this light, the need for operational processes would not be considered optional. In other domains, there is clearer delineation – for example, only developers can write code – but when it comes to content, everyone is a writer. The guidelines to be established include:
- Who owns which content. When there are differing opinions about who gets to make decisions around the publishing of content, who prevails? A clear set of protocols around content publication needs to be established. Too often, content is created and maintained within silos, and without a governance model, there can be a stalemate. A group can decide that they like recreating content in their little silo, and their circumstances are “special” enough that they get to operate according to a different set of rules. (And while that very well may be so, it has to be established as part of the governance model.)
- What are the content processes. What are the review and sign-off processes that establish how content gets created and produced? Unless there is an organization-wide understanding of how content gets adjudicated, it leaves from for waste. Are there any inter-departmental politics that could jeopardize the publication processes or content in any way? For one content type, we managed to reduce the meeting times by 84% and approval process by 99% just by enforcing a governance model that eliminated some serious political ping-pong between two engineering groups.
- Do we have a periodic review policy? And is management willing to enforce it? Have all the stakeholder groups bought into the project, or will the project be jeopardized if a critical group gets cold feet and decides to pull out?
- Budget. This may not be as straight-forward as it seems. There is likely a budget for creation of content, but what about maintenance? Or you may decide to adopt a new process that will result in significant improvement in localized content, but the localization budget may reside within another department. There may be a provision for cross-departmental sharing of the expenditures and savings, but without any agreement, some departments get very territorial about their budgets. In other cases, the budget for implementing a tool may be through a project budget, but the annual maintenance costs are assigned to another department. These issues are all too common, and all too commonly ignored until a problem arises.
Each organization has a distinct et of tensions that require operational guidelines. If you are new to governance, Welchman Pierpoint has an excellent white paper on Web Operations Management.
Myth #5: Our site is about experiencing brand, not providing content, so there is no need for content strategy.
Please excuse me while I recuperate from my laughing fit. This is every marketing executive’s wet dream: all “brand experience,” no content. I have asked around extensively, and have yet to be shown a content-free experience, let alone a satisfying one. I’m sure the YouTube experience wouldn’t be nearly as compelling if all the video content were missing, or a Martha Stewart site experience if all the articles and photos and videos were removed.
The bottom line is that the experience is the treasure hunt, and the content is the treasure. Site visitors come to find some sort of content, whether that is persuasive, instructional, or entertainment content. That is the treasure they’re hunting down. The process of finding the content influences the user experience. But, to be clear, ask anyone who has gone on a hunt – from the six-year-old at a birthday party to a site visitor looking for content – and can’t find what they’re looking for: the dissatisfaction becomes palpable. They won’t wax poetic about the great navigation or the affordance on the buttons or the whiz-bang Flash on the home page. The feedback will be that they came to the site to find out about a particular product or service and couldn’t find it. And content findability is part of a content strategy.
What are your favourite myths that involve content and its lifecycle?