Intentional Design Inc.

Talking content strategy

At the Intelligent Content 2011 conference, Scott Abel did an interview with Rachel Lovinger and Rahel Anne Bailie about a couple of aspects of content strategy. In this 9:52 video, viewable on YouTube, we discuss a couple aspects of content strategy, including content findability and the content lifecycle.

Rachel and Rahel talk with Scott Abel

The Content Brief

If you’ve done any project work, you’re probably familiar with the brief. It’s sometimes called a Design Brief, Creative Brief, or Experience Brief but it all boils down to the same thing. It’s a way to describe the problem, define the scope, articulate the goals, and reiterate the agreed-upon process to get there. In organizations, these tend to be called proposals or project briefs. Some may have a risk/benefit analysis or section on anticipated ROI, or team profiles, or other slight variations.

Despite the differences in nomenclature and  section headings, a common theme is that the content is left out of the brief. There is generally discussion of digital strategy, markets, and experience, but the content – no mention of it. Or when there is a mention, it’s in the context of how the content enhances the experience, without recognizing that the content, in many ways, is the experience.

When starting a project, I will sometimes ask to add a section to the existing brief (because agencies tend to bring in content strategists way later than that should, and the brief has already been prepared) or, if the brief has already been sent to the client, I’ll prepare a separate content strategy brief.

Colleen Jones of Content Science kindly provided her format (thanks, Colleen!), which I’ve linked to an article that gives more context for getting the most of your brief.

Content Brief

Preparing a Content Brief

Thanks to Colleen Jones for contributing this example for the series on content strategy deliverables, and stay tuned for next week’s content strategy deliverable.

Writing templates

As much as content strategists and technologists love Excel spreadsheets, writers hate them. Technologists love Excel because you can migrate all the new content into the CMS by writing a little script. Writers, on the other hand, want to use Word. Technologists hate Word because it adds hidden codes that can wreak havoc with the CSS unless they’re stripped out, but creating some sort of Word document for the writers seems to be the way to go because of the combination of needing to visualize a page as they’re writing for it, and their comfort level of this ubiquitous word processing program.

A typical writing template could look something like this. Ignore the headers and footers, and any other global navigation items. You can create a table that loosely mirrors the wireframe of each page type, and let the writers fill in the table cells. Unless there is an absolute need to set word or character count limits, it’s a good idea to leave it flexible. Ideally, the design conforms to the content, not the content to the design.

To use the template as a “cheat sheet,” additional information can be provided, depending on what is useful to the writers. If the writers are remote workers, extra information can be particularly helpful to provide context.

New business needs means new content needs

It’s a mere couple of months away to the Confab conference in Minneapolis – May 9-11, 2011, to be exact – where my contribution will be to talk about how good products deserve good content. With my reputation as a content strategy who bangs the drum about content standards, genre analysis, and metadata, and speaking about it in an accessible way, I guess the topic is natural fit. For a sneak preview of my take on this topic, you can read my contribution to the Confab blog: Content Access Must Evolve with Business Needs.

The support center reps who expertly flip through their oversized binders crammed full of product content supplemented by sticky notes is a fast-dying stereotype. As software takes over the job of collective corporate memory, the delivery of content becomes as important as the content quality. Because no matter how awesome your content is, no one can use it if they can’t find it.

If you haven’t thought about attending Confab, now’s the time to think about joining us. We’d love to see you there!

Content types

Content typing is, at its basic level, the attributes of specific chunks of content. The technical team may take responsibility for this, but you may end up having to make adjustments or to create re-use models. (It’s my experience that technologists make sweeping assumptions about content re-use that is not particularly appropriate.)  My experience is that there is no set notation system, but the integrator will be comfortable with database object definitions, and likely comfortable using that notation.

Here is an example, a news release has standard attributes: a release status (for immediate release), a headline, a city, state, country, and month, day, year, body, organization name, contact information, and an “end” indicator. A content model for a news release could look something like  this:

This gives instructions on how the integrators should create the content model, and how content flows. In this example, contact information is not created for each news release, but imported from the contact information in the repository. In that way, a changed phone number or address could be corrected all the way through the site with virtually no extra effort.

For product content, maintenance content, and other technical content, these content genres are quite mature, and have standard content models. It can prove very helpful to learn about the various types of content standards, to ensure that you’re not re-inventing the wheel, and that your content will be interoperable with other content of the same genre.

The content matrix

Depending on how you structure your content inventory spreadsheet, you may be able to add columns and extend the inventory to become the content matrix. The matrix will have columns to indicate where the content is destined – when it’s product content, that could mean not just one but multiple places, whether it can be used as-is, or needs to be edited, who is responsible for the content, the translation status, and so on. Richard Sheffield, author of The Web Content Strategist’s Bible, provides an example for anyone who has bought the book. It has a relatively comprehensive sampling of “things you might need to know about the content”.

Sometimes, a linear spreadsheet doesn’t quite do it. In that case, your job as a strategist is to figure out what format the spreadsheet should take so that it will get the job done.  In one instance, an inventory was of no use because the site revamp was so radical that the content was all new. What was important, in this case, was to convey to the ad agency writers where the content came from, and how the components and subcomponents were to be displayed so that when it did appear on the website, there would be no embarrassing repercussions. As well, it had to convey to the technical team certain things about the content mapping.

The content matrix ended up looking like this:

While I won’t go into too many details, one of the things it indicates is that the landing page actually has no content; it’s greyed out to indicate that. That content is pulled, by the CMS, from individual pages, and the related pages are listed. The subpages that feed the landing page are listed across the top, and the page components are listed down the left side. The landing page does, however, need its own page title and meta description for search engine use, which is shown at the top of the grey column, so the writers won’t forget to create it, and the technologists won’t forget to include it as part of the content modeling process.

I’m sure that comparing content matrices among practitioners, and even for one practitioner between projects, will yield a range of deliverable styles. The common theme is that the content matrix gets the job done, and that job is indicating where content will end up in the new site, and allow for technologists to customize the CMS or create migration scripts to make that happen.

The content inventory

Before you can envision the future state, you need to know the current state and determine the gap. The first step in that process is to inventory the content. Be clear – at this time, the Excel spreadsheet is a content strategist’s best friend.  If your client has a way to scrape their CMS for content, you can get a content dump. If they don’t have a CMS, or their IT department isn’t particularly cooperative, you may have to do this manually.

In the spreadsheet, you’ll need to include the minimum of the basics:

• No. – Numbers that would correspond to a wireframe (home page is 0.0, the main menu items are x.x, and so on)
• URL – To track page location; particularly helpful when you sort the columns and need to find that needle in a haystack
• Page Title – What the page is called
• Parent Section – Which site section the page is from
• Page Description – Description of the page contents (which may or may not match the URL, browser title, or page title)

Optional elements can be things like:

• Components – To capture the building blocks within a CMS, such as addresses, contact information, or product descriptions that get integrated into a larger body of content
• Browser Title – What the page is called in the browser tab
• SEO Information – meta description and keywords
• Template –  the name of the existing template in the CMS

And so on. The idea is to have as much information as you can get your hands on about the existing state of the content. Note that this is for web content that lives in a content repository that feeds the website; if you’re talking product content that is created in a component content management system or product information system, then it makes more sense to get that information directly from that system.

What do content strategy deliverables look like?

In the various online content strategy discussion groups, a recurring theme has been about seeing examples of content strategy – not the processes but actual deliverables.  My immediate response of wanting to help out gets tempered with the reality. First of all, sharing a document without the context is relatively useless, and most work is done under NDA. No one who wants to protect their reputations and their clients would expose that kind of work , and particularly in a public forum. As well, there may be some reluctance to give away intellectual property – in other words, if someone comes up with a particularly clever way to deliver value, that becomes a consultant’s competitive advantage. Giving it away is, in effect, giving away earning potential.

There needs to be a balance, though, between self-protection and sharing and support. This is the first in a series of posts that will share some of the generic deliverables that make up a part of a content strategy. However – and this is a big however – these deliverables are to be taken with a grain of salt. They are not offered in any sort of context. Some deliverables may apply to certain situations, and not to others. These are simply my way of doing things, and may not bear any remote resemblance to the way that others create their deliverables.

Building deliverables on common sense

If you were thrown off a boat into a lake, you would figure out how to swim. For the pioneers of content strategy, this was certainly the case. We reasoned out the processes and deliverables based on what we needed to accomplish by the end of the project. It’s still that way, for much of the practice. It has to be. You need to respond to existing situations, and work within the infrastructures and plans in place. It’s basic consulting practice: understand the current state, anticipate the future state, find the gap, and figure out how to fill it. Other consultants do that with finances, staff, and processes. We’re the consultants who do that with content – and what you create is what you need to get the job done.

With this in mind, over the new few weeks I will show examples of some basic deliverables. As always, feedback and suggestions are welcome, and I’ll add to the list as I get suggestions.

Surfacing content: ways to keep content in sync

One important aspect of publishing content on a website is keeping all content in sync. The content manager’s nightmare is having the same content in multiple places on a website that requires an update. Tracking where the content lives can be nightmarish, particularly when versions can fall out of sync, making subsequent updates more laborious. Having “one source of truth” is the holy grail of content developers.

A recent inquiry on the content strategy group asked about efficient ways of surfacing content in multiple ways. Yet avoiding content duplication isn’t as easy as it may sound. Managing content is more complex than managing data. Data moves from one point to another with little problem. The number “12″ is the number “12″ no matter where it ends up. But when the content equivalent – a dozen, December, above-average family size – context becomes critical.

This is where having a technical communication background comes in handy. Surfacing content in multiple places is a cornerstone of creating technical documentation, online help, training, and user support material, which can often come from a single content repository, and published out with variations. The “one source of truth” has long been articulated as “single-sourcing” with its corollary, “multi-channel publishing.”

The model for creating content and pushing it out to the surface is a different process, and uses different tools. It also moves responsibility for content further up the production process. The decision on how this is put into effect is a key aspect of a content strategy, and doesn’t get addressed often because of the deep divide between types of content authors.

One source of truth in a Web CMS (WCMS)

The WCMS  generally takes in content that is edited in form fields. A simple example would be changing the account settings of Facebook, and having those changes show on your home page. How this happens is programmed by the developers, and any changes to how the content is surfaced either by the writer (de)selecting a check box, or by the developer customizing the code of the WCMS. Thus, the WCMS is the gatekeeper for the content flow.

A practical example in the WCMS world

I recently worked on a project where a number of hotel resorts were described in various ways on the website. On the home page, there would be a one-line description accompanying a photo. On another page, there would be a short teaser paragraph. On yet another page, the hotel contact information would be shown.

In the background, all of the content was in a single database, per hotel. The database cells included: hotel name, city, state, country, reservations phone number, front desk phone number, one-line teaser, short teaser, property description, and at least a dozen more content blurbs. These were provided in an Excel spreadsheet to the technical team, who then programmed how the content would be surfaced, and ensure that the right images match the content as it is displayed.

Single sourcing in a Component CMS (CCMS)

In a CCMS situation, the responsibility for surfacing content is moved upstream, to the writer. The writer uses an XML authoring tool (as the industry matures, tools are starting to leverage common tools like Word to do XML publishing – it’s still in its infancy, though) to create content and determine the variations. The authoring tool creates a individual content files, which then get managed in the CCMS. In other words, the CCMS is not the gatekeeper; it becomes simply the “traffic cop” that supports the author’s work.

Once the writer has created the content and set up the dependencies for surfacing content, the CCMS does an automated generation of the content through some sort of publishing pipeline. This reads all of the XML metadata and determines what content is shown where. At this point, the content is generally pushed out to some area in the WCMS reserved for the content, and then the WCMS picks up its gatekeeping duties.

A practical example in the CCMS world

To publish a travel advisory that needs to be shown to three audiences, you would create the entire long-form advisory and tag each of the sections with an audience, as shown:

<public>Don’t go to country X, effective immediately.

<doctors> <industry_stakeholders>There is a suspected outbreak of a mystery disease. If called by the media, assure them that they will be informed as soon as developments are known.</industry_stakeholders> If someone comes into your office with the known symptoms, quarantine them and get them to a hospital as soon as possible.</doctors>

Stay tuned for details.</public>

The publishing pipeline would send out three separate messages to the appropriate output channel, presumably different places on the website, or a combination of the website and other forms of communication.

• The public would see the preamble plus the concluding statement (in blue).
• Industry stakeholders would see the public message plus the statement intended only for them (in blue + purple).
• Doctors would see the entire message.

Other critical differences in surfacing content

The first difference is in what constitutes the “single source of truth”:

• In a Web CMS, content changes are made to the database, and the content is changed everywhere it’s programmed to do so. The database is the single source of truth.
• In a CCMS, what you have is, in effect, two “single sources of truth” – one is the pre-published source; the other is the published version. The nature of publishing is that these get out of sync after version 1. Think of publishing a multi-hundred page HTML manual. Version 1 uses all new content. Then, there are updates to one section, say pages 20-30. These pages now have Version 1 content and Version 2 content, while the published content is all in the Version 2 manual.

So the second difference is how content is versioned:

• The authors will be concerned with the versions of each content file; after a while, a body of published content can be made up of a range of versions that co-exist in the same repository and get mixed-and-matched by the author to be published.
• The published content is another single source of truth. It is the aggregated “publication” that is for consumption. The consumers of this content have no idea that any given page may be made up of multiple content chunks aggregated together for a seamless reading experience.

Another difference the gatekeeping functions:

• In a WCMS, the code written by the developer provides virtually all gatekeeping functionality.
• In the CCMS, the writer is the primary gatekeeper, but there is another gatekeeping function – the publishing pipeline code. The content is generally publishing using XSLTs (an automated transformation of XML content using XML stylesheet language scripts). The code automates the output process, and changes to the output means tweaking the scripts.

The WCMS world vastly overwhelms the CCMS world in number of systems sold and implemented, though amount the content published by CCMS systems on a given site often considerably dwarfs that output by the WCMS.  The next few years will be interesting, as content management systems try to capture market share by enabling “the other type” of authoring experience for organizations that need to adopt more robust methods of creating and surfacing content in more flexible ways.

Pushing customers away with bad user experience

Dear Imperial Oil,

I’m sure you have user experience people helping you, but I’ll bet you don’t implement half of what they tell you. If you did, I wouldn’t be writing this blog post explaining how to lose supporters and antagonize customers.

I have received my snail-mail letter explaining that I need to update my credit card to use my Esso Speedpass key tag. You give me some instructions, but they don’t  cover my situation.

Your website isn’t helping me because:

1. I exceeded my number of logins – after all, it’s probably been years since I last went to your website – and now am told to call your Customer Service Center.
2. Self-service is faster, supposedly, but your “help” center doesn’t answer my question and your FAQs are, well, not particularly helpful.
3. I fall back on the old telephone, but phoning your customer service center won’t lead me to a customer service agent. AND, pressing “0″ just sends me back to the opening menu. (Your support content is definitely not aligned – where is the consistency?)

So, now I’m kind of stuck. On one hand, you’ve made it so painful for me to rectify my problem that my next step is likely to toss my key tag into the trash, shred the letter, and put this experience behind me. I know the score; I’m a single lone customer in a huge pond, and you couldn’t care less whether I renew my account or not.

On the other hand, I like the convenience of a key tag.If I really, really wanted a new Speedpass tag, I could report mine lost, and you’ll send me a new one and all the problems will get rectified, in the course of setting up a new account. But thinking into the future, I’ve already had to replace my credit cards a couple of times this year alone.  Do I want to go through a dead-end voice mail tree each time I need to update my account?

So, Imperial Oil, listen to your user experience folks. I suspect I’m not alone in considering the barriers you’ve built into your customer experience, and deciding it’s easier to bail.