Intentional Design Inc.

Technology won’t fix a bad strategy

For a few years, after a particular rounds of a presentation on principles of component content management, a number of the audience members would inevitably hover around the stage, looking either excited or agitated. I assumed the latter, and would wait for the questions that were so obviously bubbling up for the writers and managers that milled about.

“Our IT department gave us VSS and we can’t figure out how to get components out of that. How do you do that?”

“We’re tearing our hair out with Sharepoint and versioning; what is the workaround?”

“Our website uses Documentum and it won’t do what we want. What do we do?”

“We have Interwoven and the interface is awful, so our staff won’t use it. What should we replace it with?”

Each set of circumstances was unique, yet eerily alike.  Each instance involved the acquisition of a software product which was then implemented for an operational unit, without regard to whether the software was suited to the task. The mismatch, in some cases, was painfully obvious; in other cases, the mismatch was more subtle. In many cases, certainly all the instances above, the software is popular, thriving software that has been implemented without a proper strategy. The results: generally some sort of fail.

Bad strategy or no strategy?

During the past decade, acceptance of content management has drastically increased. The idea that managing any significant volume of content requires some technology assistance has been demonstrated a multitude of times, and the adoption of a CMS (content management systems)  is no longer a novelty. Yet the instances of the tail wagging the dog – buying the software before determining the operational needs – continue to be far too familiar to ignore.

When I would encounter an audience member at a later event, I’d ask if they’d ever gotten the problem sorted out. Overwhelmingly, they would sheepishly admit that they had not. They continued to produce and publish content in ways that they acknowledged were highly inefficient and prone to operational risks <link> because they couldn’t convince their organizations of the need to make the changes that, to them, were obviously needed. So what went wrong?

Go cheap or go home. This “strategy” is when the technology group either already has some software – collaboration software, source code control software, or a Web CMS – that they insist be put to use because “we already own the software” or “the software is free.” Not only does this dooms a project to failure, but anecdotal reports show that the operational team is then blamed for the failure. The technology group refuses to take responsibility for having foisted upon them an inappropriate tool. In this case, a stalemate ensues, and everyone goes back to their previous kludgy way of work, with no movement forward, and the technologists smug in their political win.

Don’t get it, don’t care; just do it. This “strategy” is in play when a group has heavily invested in a software application, and is reluctant to investment more time or money to make it work for a different operational purpose. There is equal resistance to bringing in additional software that complements the original uber-application, and no impetus to understand why it is needed. There may have been a strategy developed for the initial implementation, but there is no acknowledgement that different operational needs will require further customization of the software. The idea is that the software should be one-size-fits-all, and if the customization has worked from one department, it should work for all departments. The department whose operational needs aren’t being met is sure to find inventive work-arounds, sometimes taking pains not to let on what is going on for fear of sanctions from the powers that be. Generally, the situation comes to light when a serious breach of protocol comes to light that can be traced back to a work-around that failed.

Connecting strategy to technology

The idea that technology can be implemented without strategy is naïve, at best. The idea that technology or strategy can be implemented without a deep understanding of the content lifecycle is a wanton mismanagement of corporate assets.

Understand your content. The entire CMS implementation is to support, with technology, the production, processing, and publishing of content. It is imperative to understand what the content needs are throughout the entire content lifecycle. Without this understanding, a technology implementation is sure to go wrong at some point because there will be a mismatch between the content requirements and the software assigned to support it.

Know your standards. For any technology to be effective, there needs to be an understanding of how the content can be leveraged. This generally involves connecting systems, whether that is as simple as providing an RSS feed or using microformats, to more robust standards such as implementing DITA <link> to make content system-agnostic or integrating content from one system into another through the magic of XSL transformations.

Understand pertinent technologies. The decision-makers who, with much eye-rolling, confess with some pride that they don’t even know how to use styles in their word processing are who allow bad software implementations to thrive. Get with the program or get someone who can, because the lack of understanding about how to leverage content through technology, more often than not, shortchanges the project or leads to disastrous results. The complexity of systems has grown exponentially over the past decade; it is imperative to understand, at least at a high level, what the various technologies can do and how that can benefit – or harm – your content and, ultimately, your brand.

The concepts I’ve articulated here are not entirely new, nor are they particularly rocket science. Consultants, software vendors, and their savvy clients have produced many case studies demonstrating successful implementations and the derived organizational value. Invariably, their successes all share a common denominator: a strong strategy.

Popularity: 1% [?]

CMS Facts and Myths, and Why Process is So Important

Earlier this week, I published a guest post on CMS Myth about the top ten claims (or misrepresentations) that CMS vendors make. The post arose from a discussion between me and two other long-time consultants on the trade show floor of a conference. We had been in separate sessions during the day, and heard various speakers – some of whom worked for software vendors – represented their software to the audience, and our ears pricked up as the familiar “check is in the mail” claims got sprinkled amongst the facts.

Of course, a presentation is just that. It’s generally an hour-long session, in which a speaker has to pick and choose their facts and explanations to fit within the time frame. Sometimes large issues get glossed over in order to fit in all the great material the speaker wants to present.

CMS-savvy people – internal staff to project stakeholders to consultants and everyone in between – know that there can be inadvertent, besides deliberate, misrepresentations of what a system can do. It’s often a mismatch between a system’s features and organizational needs, and often a mismatch between cost models and budget expectations. So how do you ensure that you’re not  left holding the bag when the software vendor has left the building?

Process.

When you can explain to a vendor exactly what you need from a system – the scenarios and use cases – then you can get the vendor to demonstrate how their system will fulfill that need, how much it will cost for add-ons or customizations, how long it will take to accommodate all of this, and what impact all these will have on the maintenance after an upgrade or two. Without doing all of your homework first, you fall prey to the never-ending escalation of time, cost, and frustration as you discover the shortcomings of a misfit content management system.

Popularity: 1% [?]

Skills to transition to content strategy

You may say that all this is fine and good to position content strategists as the management consultants of the content world, but what does an aspiring content strategist do with that information? What concrete steps can you take to make the move to content strategy?

I quite dislike the laundry list approach to skill sets, and avoid the allure of “top ten” lists  that are supposed to be a one-dose-fits-all remedy. However, in an attempt to provide a succinct resource that can be useful to those wanting to round out their knowledge, I’ve created a suggested reading list. It is not meant to be a definitive list, and likely has more benefits to technical communicators who want to manage large bodies of technical content with more efficiency. However, I stand by my belief that those wanting to make the transition to content strategy will benefit from havin some knowledge  in each of these areas. I’d be interested in feedback and additions.

Requirements Analysis

• Identify business needs
• Understand corporate motivations and goals

Deliverables:

• GAP analysis
• Requirements matrix
• Process models

Learn from:

International Institute of Business Analysts – Body of Knowledge

Information Management Center – Information Process Maturity Model

User Analysis

• Identify key audiences
• Understand user motivations and goals or tasks

Deliverables:

• Needs assessments
• Personas and scenarios
• Flow diagrams

Learn from:

Ethnography

The User is Always Right

UI Flow Diagrams

Content Analysis

• Take inventory of existing content and documents
• Categorize content

Deliverables:

• Content inventory
• Content audit
• Metadata taxonomy
• Content models
• Content architecture
• Wireframes
• Delivery design

Learn from:

Adaptive Path on inventory

The Rockley Group on audits

Gerry McGovern on metadata

Content modeling

Content standards

Information Architecture Institute

Multi-channel publishing

Get Content, Get Customers

Content Design and Production

• Production workflow analysis
• Create content business rules
• Design content
• Develop content

Deliverables:

• Business process maps
• Topic maps
• Customization and personalization maps
• Localization plan
• Page tables/layout templates
• Standards and style guides
• And, of course, the content

Learn from:

AIIM Training Programs

Steve Pepper on Topic Maps

Letting Go of the Words

Web Content Accessibility Guidelines

The Culturally Customized Web Site

Content and Technology

• Managing content
• Content standards
• Content management systems

Deliverables:

• Technology recommendations
• Implementation strategy

Learn from:

Content Management Bible

W3C Standards

OASIS Standards

LISA standards

Wikipedia review of CMS types

There are a few resources not included in this list, only because they span multiple areas mentioned above. These are the books about content strategy, whether or not called by that name:

Managing Enterprise Content: A Unified Content Strategy, by Ann Rockley

Web Content Strategist’s Bible, by Richard Sheffield

Content Strategy for the Web, by Kristina Halvorson

Information Development: Managing Your Documentation Projects, Portfolio, and People, by JoAnn T. Hackos

As a final note, hats off to the founders of the content strategy knol (unit of information) where practitioners are welcome to contribute resources, to consolidate information into a central location.

Previous posts in this series:

The extraordinary world of content strategists

Abilities and aptitudes for a content strategist

Content strategy: the skills conundrum

Popularity: 3% [?]

Content strategy: The skills conundrum

A content strategist should have a range of skills that span the particular practice area. Going back to my metaphor of the medical field, a dentist will have a different set of knowledge than a pediatrician. Similarly, a content strategist in a PR agency will require different skills than one focusing on user assistance. While both content strategists will have common baseline knowledge of content, the specialties could be significantly different.

For example, a content strategist in the user assistance field – technical documentation, help, training, support, and related content – should know enough about the differences between major content development processes and technologies to be able to know about content migration, optimization, workflow, delivery, and management within that realm of content. Does that mean a deep knowledge of RoboHelp, Flare, Author-It, Vasont, SiberSafe, XDocs, XMetaL, XML Mind, RenderX XEP Processor, Antenna House Formatter, DITA Open Toolkit, and whatever other Web CMS, SharePoint, or collaboration tools are out there? No, absolutely not. However, the strategist needs to have enough experience with a range of these tools to know the differences between how they process content (and the determination to find that information). The strategist also needs to know how to exploit the content, and how to determine which system works in which situation.

A typical job posting for a content strategist focuses on the abilities needed to make strategic decisions. Here is one such example, which asks for:

• 2-3 years experience in online content strategy, particularly as an Information Architect or Web Content Manager
• Ability to develop user scenarios to better sort and display various types content
• Ability to create and edit prototypes and IA deliverables
• Experience writing and editing content for the Web
• Knowledge of web standards, including W3C compliance, accessibility (section 508) and the SEO implications of information architecture
• Understanding of the capabilities and limitations of Web technologies, including cross-browser compatibilities, HTML, XHTML, CSS, JavaScript, XML, AJAX, PHP, Flash, Flex and mobile computing
• Ability to clearly articulate to internal team as well as clients the reasoning behind usability choices and recommendations
• Strong organizational skills and a basic familiarity with [a popular CMS]
• The ideal candidate will also have work experience in providing content strategy recommendations.

However, the temptation of organizations to simply ask for a laundry list of software skills has already begun. This approach, known in professional development circles as lazy recruitment techniques, confuse knowledge of a tool with quality work. A quick Web search revealed this post from a recruitment agency who seem to think that a Web developer with some creativity and the ability to articulate to stakeholders makes for a good content strategist:

Required skills:

• Drupal, CSS, Photoshop, Flash, Action script, Adobe CS2+, Google Analytics, WordPress development. Experience in Joopla recommended.
• Proactivity: A key part of what this role involves innovating the way of communicating our content through the web. Success in this role will require the ability to articulate, argue for and proactively push through your own creative solutions to problems.
• Proven track record of success in prioritizing and managing multiple projects, project forecasting, and resource planning
• Excellent verbal and written communication skills – comfortable explaining problems, options, and decisions to stakeholders

Education/Experience Requirements:

• Bachelor’s degree required
• 5+ years’ experience in a web management environment

This  organization (and many others like it – this example is by no means unique) may say they have a “strategic position requiring excellent project management and user interface expertise, as well as strong collaboration skills and a strong passion for [our] mission of principled performance. The ideal candidate will have experience visioning and implementing strategy to align content with the user experience and has the technical skills to work with the Drupal content management platform” but is that really what they mean?

What they are actually saying is that they’re not sure what a content strategist does, so they will list some software packages and a few skills having little to do with the actual development, management, or delivery of content (and that tend to be mutually exclusive – big picture thinkers are rarely detail-oriented) and see what happens. In the vein of “the music is not in the violin,” the ability to use a range of software tools is not what makes a good strategist. Many industries “hire for aptitude; train for skills.” This seems like sound advice for the emerging practice area of content strategy, particularly because so much of the work is tied to aptitude.

Related posts:

The extraordinary world of content strategists

Abilities and aptitudes for a content strategist

Skills to transition to content strategy (coming June 16th)

Popularity: 1% [?]

Abilities and aptitudes for a content strategist

For some careers, there is an established path. There are educational programs, professional development paths, professional association training programs, and mentors to guide those wanting to make a career transition. In the world of content strategy, not so much; there are no college programs, professional certificates, or training courses through professional associations. Given the lack of readily-available information, what does one look for when engaging a content strategist? Or, from the perspective of a content strategist, what should you be prepared to bring to the table?

Putting myself in the hiring chair, I would look for someone who works well within a T-shaped creative process.  The linked graphic is from David Armano, and meant for professionals working at the intersection of interactive marketing and experience design. However, these are the same talents distinguish content strategists from smart writers or smart technologists. These are the people who have insights into content, can develop a big idea from a content corpus, and articulate that idea in conceptual terms. They have to care that content is not just useable, but useful and desirable.

Let’s face it, a single strategist likely can’t be a master at all the details in every aspect. However, the strategist is not the person who asks: how do you want this content delivered, but after an analysis, tells you how the content should be delivered, and why, and to what benefit. The strategist should be able to do so using core consulting methodology, simplified here for sake of space: determine current state, analyze the requirements (of the business, content, and users), determine future state, identify gaps, and create a roadmap from current to future state.

Understanding the nature of content – from genre analysis to taxonomy to delivery models to line editing  – is a given. Processing content is not like processing data; it’s a lot more subtle and complex. A content strategist needs to have some sort of content background – English, writing, journalism, library sciences, translation, or related fields -  to understand the qualities and properties of content. You may be able to inventory content without understand a lot about its nature, but undertaking any sort of content analysis or taxonomy effort or content rewrite implies some measure of skill at content development.

The content strategist should be able to work as part of the larger team, whether that be a CMS project team or an ongoing user experience or creative group or product development team. More importantly, a strategist should understand how important it is to be part of the big picture, and understand how to integrate the content strategy within the larger organizational plans. This means an understanding of traditional and emerging business models, and communication paradigms that support various types of marketing and customer relationship efforts. It also means that sometimes the strategist may be called upon to create what are generally thought of as information architecture artifacts: conceptual IA models or wireframes. Though this may be a small part of the overall activities, knowing user-centered and experience design processes is an important part of a content strategist’s toolkit. Knowing how to apply these techniques to content is definitely worth bonus points.

It also helps when content strategists are technology aware – in other words, knowledgeable enough about current and emerging technologies that they can recommend strategic ways of implementing content. In other words, they are not the carpenters to whom every problem looks like it needs the same hammer-and-nail solution. I’m not talking technical acumen – there are way too many complex software apps out there to be both a content strategist and technologist. But the strategist should have enough conceptual knowledge to understand how content should or could flow through a system, and which types of systems will deliver the goods for a particular business need. This means system awareness, knowledge of implementation best practices, content migration  techniques, content standards, and an understanding of the interrelationships between people, processes, and technology.

Related posts:

The extraordinary world of content strategists

Content strategy: The skills conundrum (coming Jun 14th)

Skills to transition to content strategy (coming Jun 16th)

Popularity: 2% [?]

The extraordinary world of content strategists

Content strategy is a big field. It’s a conceptual category that encompasses numerous fields of practice. Talking to someone about content strategy as a career is like talking to someone about being a doctor. The profession of doctor encompasses everything from neurologist to podiatrist, and all body parts in between. Yet there is a unifying theme, whether a doctor is a gerontologist or pediatrician, psychiatrist or orthopedic surgeon. Doctors start with the same training to understand basic functions of the human body, and then specialize in a chosen area.

Content strategy is a little like that. We are practitioners who understand content. We understand it at a level that many people never stop to consider. We understand the potential of content in ways that others overlook. We understand how content connects to other content, how the development and delivery of content affects, and is affected by, practices connected to our profession, and how content connects to content consumers.

Where content strategy differs from the medical metaphor is that our understanding comes, not from a common educational background or some content boot camp, but from a wide range of professions. There is no Bachelor of Content Strategy upon which you can build a specialization in technical communication, marketing communications, social media, or enterprise content. Instead, practitioners come to the content strategy table with their specialties already in place, and stretch their wings to embrace ideas beyond the confines of their existing fields of practice.

Makings of a content strategist

The model for content strategy is more like  that of management consulting. Every management consultant has come from a different background – accounting, operations, technology, communications – with the commonality of understanding industry best practices, and being able to apply them appropriately, according to the situation. In fact, the Wikipedia definition of management consulting is both the industry, and the practice, of helping organizations improve their performance, primarily through the analysis of existing business problems and development of plans for improvement.  Using this paradigm, then, a content strategist is a management consultant with a specialty in improving performance of content.

The Wikipedia article on management consulting goes on to explain that “consultancies may also provide organizational change management assistance, development of coaching skills, technology implementation, strategy development, or operational improvement services. Management consultants generally bring their own, proprietary methodologies or frameworks to guide the identification of problems, and to serve as the basis for recommendations for more effective or efficient ways of performing business tasks. ” This sounds a lot like what we do as content strategists:

The skills to look for in a content strategist, then, can be specialized – for example, a content strategist working with newspapers concentrates on areas different than the strategist dealing with website marketing, who concentrates on areas different than the strategist dealing with user assistance content – but share some common underlying qualities.

Next posts in this series:

Abilities and aptitudes for a content strategist (coming Jun 11th)

Content strategy: the skills conundrum (coming June 14th)

Skills to transition to content strategy (coming June 16th)

Popularity: 3% [?]

Dispelling More Content Myths

My last post was about myths related to the content lifecycle. This post continues with five more myths, more to do with content than the actual lifecycle. However, some of these myths indicate a lack of content strategy. It could mean lack of editorial strategy or social media (yes, that’s content, too), or collaborative documentation strategy, or deficiencies in content modeling, or lack of a technology strategy, or a combination of several aspects of the overall content strategy. The technology aspects of the content lifecycle may be addressed quite thoroughly,  but that only deals with the “containers” into which the content fits. There are separate aspects of a content strategy that address the aspects to which the content itself needs to adhere.

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?

Popularity: 2% [?]

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?

Popularity: 2% [?]

Content Lifecycle

The issue of content lifecycle has been on my mind lately, particularly in the context of lack of awareness about content having a lifecycle, or a truncated awareness of content in terms of its lifecycle. If anything would jar me from my lethargy around posting to my site, this would be the perfect topic.

Perhaps the lack of attention to content lifecycle is a reflection of the lack of attention given to the topic on the Web. In fact, a Wikipedia search on the topic of the content lifecycle sent me to the topic of Content Management, where a brief mention of content lifecycle management involves “content distributions [sic] and digital rights” – if only it were that easy. The German version of Wikipedia has an article on the content lifecycle for Web content, which seems incredibly simple (Create > Publish > Archive? Really?) and is also tied to a content management system.

But, I’m telling you, this is wrong, wrong, wrong. At the risk of sounding like David taking on Goliath, I want to spend a couple of articles talking about the content lifecycle, and clearing up some common misconceptions. I’ll discuss  content without the attachment to a CMS, proprietary software, tools, or methodologies. It’s all about the content, front and center. Defining a content lifecycle What is a content lifecycle?

Just as in the information architecture world, there’s “big IA” and “little IA”, in the content world, there is “big content management” and “little content management”. The “little content management” is about getting content to work within a content management system; “big content management” is about having a content strategy to create a repeatable system that governs the management of the content, throughout the entire lifecycle.

The content lifecycle covers four general areas: the strategic analysis, the content collection, management of the content, and publication, which includes post-publication maintenance and a loop back to analysis for the next cycle. This lifecycle is present whether the content is controlled within a content management system or not, whether it gets translated or not, whether it gets deleted  at the end of its life or revised and re-used.

The critical aspect of the lifecycle is that it begins with the analysis quadrant. The saying, “if you don’t know where you’re going, any road will take you there,” certainly applies to the lifecycle  of content that begins without a strategy. You can change how it produced, how it’s managed, which tools you use to control it, translate it or not, cut aspects out of it or not – if you have no strategy, you have no real rationale for the content you produce.

The other three quadrants are the tactical aspects of the content lifecycle.  They may not have the same allure as the strategic side (at least, not for me), but they are important, nonetheless. It’s where the rubber hits the road. Without the strategy, you may end up in an aimless wander, but without the tactical side, all you have is a good idea.

Next week: Dispelling the Top 10 Myths about the Content Lifecycle

Popularity: 2% [?]

Satisfying the cat: a user-centered design metaphor

Through the power of social media, where I gather this video has been circulating at the IA Summit, I can bring you this video by John Boykin. It’s a great way of explaining user-centered design to clients and related stakeholders. It’s along the same lines of what David S. Platt says in his book Why Software Sucks … and What You Can Do About It: Know thy user, for he is not thee. Platt uses real-world examples and statistics to illustrate his point about knowing your users, which works for audiences of developers and other industry insiders.

Boykin’s approach, in a YouTube video called Satisfy the Cat, works well to illustrate the relationship between web designer, client, developers, and end users, and why a user-centered design process, instead of a client-centered design process, is important to grease the wheels of business.

Popularity: 1% [?]