A big thank-you to Destry Wion, Allison Casey, Melanie Seibert, Will Sansbury, Mark Poston, and contributors @crockerpayne and @anindita for contributing their favourite myths.

Myth #6: We have a social media strategy so we don’t need a content strategy.

Social media is a bit of a misnomer. It should be called social content, because the text, photos, video, and other contributions by the various participants is all content, and that content needs to be managed. And not to belabour the point, it needs to be managed through a content strategy. For example, if your social content consists of user-generated  product discussions, your social content likely supplements, extends, or at least supports the official documentation provided by the organization. Unless there is a content strategy for presenting both types of content in context, there is potential for chaos. The organization needs to make decisions around content creation, curation – how to wrangle all that contributed content so that it becomes useful to the content consumers, presentation, and preservation – a review and retention plan. The social content cannot exist in a divorced state from the rest of the corpus; the content strategy should look at the lifecycle of all content types and the interactions between them.

Myth #7: We know how people read our content, and that’s mostly what content strategy is about.

This myth encompasses a number of assumptions (often unsubstantiated, but that’s a whole other post) about how content consumers access, read, and otherwise use content. It’s worth looking at some of these assumptions before discussing how they fit into a discussion of content strategy and the content lifecycle.

• The only content people see is “above the fold.” Actually, research says differently. Without diverging into the topic of scanning vs reading, and how people navigate browse paths, let’s say that you’ve adjusted your content to optimize its use by your primary user groups. This is a single aspect of a content content strategy that affects one quadrant of the content lifecycle: Collection.
• Good content fits within the site design constraints. If you constrain content to the number of words that “looks right” with the graphic design, this is a classic case of the tail wagging the dog. The site architecture should  start with the content that needs to be presented, and the design should support that.
• We can leave it to users create the content. A naïve assumption is that if you build it, they will post. If you think that users just can’t wait to contribute awesome articles to the wiki-powered tabula rasa provided, you may be in for a nasty shock. There are success stories about organizations whose users clamored for a collaborative space to share information, but these are success stories because the implementation came after the content strategy was formulated. The Web is littered with not-such-success stories, where a wiki was slapped up without a sound strategy behind the implementation.

Myth #8: We can implement a content lifecycle without doing the basics: content inventory, audit, and analysis.

Definitely not. Listen, if you’re going to start by launching your site for France, don’t give me a file scrape from Brazil (because it’s smaller, so supposedly easier to categorize) and expect me to come up with a proper inventory, an accurate number of content types, or migration strategy. This statement may seem so obvious that it doesn’t need to be stated, but this scenario comes from a client (sanitized to protect the guilty parties, of course) in 2010.

Myth #9: The more that content is version-controlled by conventions (version number, file name, URL, and so on), the harder it is to maintain the content and its links.

The inability to manage properly versioned content is no more than a lack of imagination. Or a lack of willingness by corporate or departmental policy to accommodate it. Or both. Corporations that are vulnerable to negative consequences arising from delivery of incorrect content have figured out how to manage content versions in an appropriate way. They’ve realized that the ROI on investing in processes and/or technologies that support the management of content is far more advantageous than saving $100,000 only to lose a lawsuit of $1 million. I am not making up these numbers; my own clients and the clients of some of my mentors have cited the need to manage content with attention to version details involve sudden expenditures in terms of fines levied by regulators, lost lawsuits by injured customers who inadvertently misused a product, or loss of confidence by potential clients after adverse publicity arising from negative reports. All these examples have content-related disasters attached, some of them compounded by a lack of audit trail and poor versioning. A good content strategy should address this issue, and similar issues, and taking the time to develop the strategy pays for itself in no time.

Myth #10: More content is better content.

This myth should be called the “compensate for lack of quality with copious quantities of content” myth. When you don’t determine which content is appropriate in which places, that points to a lack of strategy. You can’t compensate with unfocused content, inaccurate content, wordy content, or other sleight-of-hand techniques. Can you imagine looking for a specific piece of information, and finding all sorts of irrelevant content? Oh, you probably have. And have made fun of the site, and perhaps told your friends in a ditting contest for who has had the worst user experience. Or perhaps told the world in a fit of pique through a Twitter post. And if this is your site, then it could be the butt of some of the same jibes, too.

I’ve had plenty of opportunity to watch fourth-year engineering students, employed part-time as computer technicians for organization such as Best Buy’s Geek Squad, look for content on the Web. They are usually searching for a solution to an esoteric problem with my laptop. These impromptu glimpses into  how they search for content has been fascinating. They do a Google search and choose the top result. If the content fills the screen, they immediately click the browser’s back button and go to the next search result. When I protest that in my speed-reading, I thought I saw the answer in the last paragraph on screen, they brush me off with a terse: “oh, it takes too long to read” and “I’ll find something shorter.”From their reactions, and what I’ve come to see as a wider reading pattern, is that readers often perceive it to be faster to look through search results for the page of content with the shortest, most concise and focused answer, than it is to read one or two longer pages. I may not agree with them, but I have observed this frequently enough that I no longer discount it as an behavioural anomaly.

These are the myths that made my Top Ten list. What are your favourite myths related to content strategy, the content lifecycle, or content itself?

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?

So when it came time to changing the answering machine greeting message, I followed the instructions only to discover that there is no option to select. I tried all the little tricks to see if the option got hidden elsewhere in the menu tree, but it was definitely missing. Well, that’s fine; I will tough out the pain of contacting customer support, through the phone number in the back of the book. The phone number works in Canada – always an iffy question – so that’s encouraging, and after listening to all the preambles, I press 1 for English, enter my product number, and go through the various menus but there is no option for “menu items are missing”. It seems that all the options end up the same way, leading to an end point of “visit our website at …”.

Now, gigantic corporations all have us trained to despise having to call in; in other words: Don’t you think I’d have checked the website first if I thought I could find the answer on your website? It would have been so much easier: go to the site, choose the model number, and  But of course, the user experience was quite painful. Here is an encapsulation of the frustration points:

1. After doing a Google search for AT&T 84209 (the model number) phone, I kept getting routed to the att.com site, which was obviously US-based, and geared to telephone service subscribers.
2. I redialed the number from the instruction book and was given www.telephones.att.com as the URL. Typing in 84209 got me to a shopping area. Do I want to buy a replacement cordless battery? I must say that if I happened to know the model number of a phone I wanted to buy, I’d be in luck because the second shopping option is to buy the very phone that I’m getting annoyed over.
3. There are links to the manual and Quick Start guide, which I consulted and had the same incorrect information.
4. Filling in the Contact Us form field promises to net a response within – depending on which of the messages you believe – 72 hours (on website), 2 days (on-screen auto-reply message), or 3 days (auto-reply email) but I doubt that I’ll get a meaningful answer. It may be too late anyhow, as I’ve run about the house, disconnecting telephone bits and bobs and tossing them into a bag to return to the store.

Now, I admit that my question is not one of the top ten questions, and it might be embarrassing to put it on the automated reply options (Press 8 if the interface  doesn’t work as per instructions.) but surely someone has asked this question before, and somewhere, a content developer has tackled this discrepancy. The point is that there needs to be a strategy around content that goes beyond the basics. Now that I’ve calmed down and revisited the situation with an industry insider’s eye, the support site is lovely – beautiful colours and the navigation to the FAQs is quite simple. But when a customer is searching content, and can’t find it, then all the other niceties fall away. The laser beam focus on finding the content, which is needed to complete their task, overrides all other aspects of the user experience. Task-based analysis at its best.

So to AT&T, I would ask: if one of your questions is “Who is Charlie Johnson and why is his name displayed on my phone?” surely the question of missing menu items could be addressed, as well? This site is a classic example of focusing resources on the usability side of the support site, but not having a content strategy befitting such a site.  In this case, I did receive an email a few days later, referring me to a “real person” in another department, but by that time, my answer was, “Thanks, but too little too late. I’ve exchanged the phone for another brand.”

Seeing as how returns of electronic consumer products is a multi-billion dollar problem in North America, companies could definitely benefit from having strong content strategies, not just on their website, but across the product line, from instructions to training to their support site.

Content can be described as “everything” (Rachel Lovinger quoting Chris Sizemore) but let’s refine that definition to something more tangible, a definition that can be employed by practitioners and stakeholders for the purpose of designing user experiences.

Simply put, content is contextualized data.

A few years back, I read an anecdote about someone who would send the Google folks a period email with a number. That was the entire email, a single number. Eventually, the recipients figured out that the number was a comment on too many words on the Google home page. Was that email content or data? There is no absolutely right or wrong, but I would posit that without the context of the number, it wasn’t content, it was data.

The number 12 is an example of data. It may have a context in the sense that we know it is more than 11 and less than 13. But it doesn’t have meaning for a reader until there is a practical context:

• a dozen eggs
• December
• players on a team
• children on a schoolbus
• dollars to purchase a product

There is a different type of contrast:

• http://www.bestbuy.com/site/olspage.jsp?id=abcat0101000&type=category
• http://hypem.com/artist/joel+plaskett

In each case, the commonality is that the context that helps with cognitive processing of content.

The practical application of this definition of content could be understood through the following example. A catalogue in a catalogue will have content attached to it: a product description, a photo, perhaps a video of the product in use. There will also be data that gets attached to the content – a SKU, a price. As soon as the data can be understood in context, it has become part of the content.

Content strategists understand the importance of managing content throughout its entire lifecycle, from analysis of business requirements and planning right through to archiving and forensic e-discovery. I believe that what differentiates us from the information management side is that we don’t treat information as data to be managed. For us, context is a critical part of designing the user experience. So while information management and content management is more consumed more with the technologies behind the management and delivery mechanisms, content strategy is closer to the contextual understanding of content, including contextualized data, for the benefit of the consumers of that content.

There are two types of people, I’ve found: those who read the tags, and those who read between the tags. A couple who exemplify this are my accountant and his database administrator wife. When I turned up there wearing my content strategy t-shirt, they both studied it intently for a minute. Her reaction was: yep, you wrote valid code. His reaction was: can you tell me what a content strategy is? at which point we all realized that she’d read the tags but hadn’t absorbed what was inside the tags at all. 

Content Strategy t-shirt

This was consistent with the reaction I got at the IxDA conference, where the “blank canvas” t-shirts were handed out. The coders read the tags but had to be reminded to read inside the tags. So what do you do when you’re the one who cares about what’s between the tags more than the tags themselves? (Or you’re like me and think the tags are just as important as the content within, for various reasons I won’t go into in this post.) This is where you need to know the technology options that support your content strategy. This is what separates strategists from writers.  

At many of the conferences I attend, there’s a fellow there who promotes a product that analyzes all the content within [a site, repository, code, etc] and will tell you where certain terms are used, and when terms are used “almost but not quite” the same, and so on. I know about this tool because it’s used by organizations that have buckets and dump trucks full of technical content that needs tracking and translation, and this tool assists with productivity when you have, say, ten or 500 writers who need to write in the same style and use consistente language. (Example: One simple instructional sentence was written with over 300 variations – that alone represented thousands of dollars in translation costs by the time it went into multiple languages.)

So reading the “measuring content strategy” post made me think: wait a minute. If the organization in question has such a “sprawling” site, surely they have such a tool, to make it easy to find, analyze, track, control and otherwise manage the content at the word level (as opposed to the tag level). I’m not mentioning the tool – this isn’t about product placement – because of the importance of knowing about the resources out there that are available to us as content strategists, and knowing when they could be used and to what purpose.

The blog post states: “If a customer lands on a website and leaves because the content was irrelevant or unprofessional, we won’t have the chance to say, “Hey! Come back! That’s not really us. We just threw some stuff up there until we have money for good content.” That person is gone, baby. And we may never know it.” From all the studies done in the UX field, we know how fickle site visitors can be, and we’re right to be concerned about that content between the tags. Equally as important is to arm ourselves with the ammunition to justify how we can keep that content on track.

Using the music industry as an example of an industry that gets the most from its content, this presentation illustrates ways to make your content be both useful and a delight to your customers.

Other times, the mid-stream transformation is done by humans, and ingested back into the system for further transformation. Localized content fits in this area, and the implications can be far-reaching. The drive to package content into neat little bundles, so that they can be re-used in multiple contexts, is difficult enough to carry out for a single language or homogeneous market. Writing to satisfy the complexities of multiple languages or localized markets creates exponential challenges. Further complicating the situation is the fact that the people charged with transforming your content are usually outsiders, and probably haven’t been included in the sessions that taught the concepts and developed the architecture for the new content order within your organization. Not only do your translators have to figure out how your content convergence strategy is intended to work for you, they have to figure out how to retain the accuracy and flavor of your intent across languages and cultures. It’s a tall order, and an aspect of content convergence often overlooked.

There’s an article, Anticipating the Impact of Content Convergence, in the January/February 2009 issue of Multilingual Computing that elaborates on some of the things translation professionals, and their clients, need to consider as the nature of content undergoes a profound change.