Content Strategy: Content Modeling a Beginner’s Guide

Go to article

Posted on September 28, 2011

by: Ann Rockley

This blog post was inspired by a discussion on the content strategy list serve. I started writing a reply and found that I quickly wrote a response much too long for the email thread. Caveat, the samples I have provided are very top level, but hopefully useful.

A bit of background

The thread started with “I am looking for resources on the “how to” for content strategy, mainly content modeling, creation of a content framework, etc. It would be great to get links to resources, templates or examples on how to go about creating these artifacts.”

There were a number of good responses and the topic of XML and DITA came into the discussion, somewhat overwhelming the novice content strategist.

There was a statement today, about “my advice is to not worry about DITA and XML.” Which I both agree and disagree with.

So here’s a primer on the way I think about content modeling.

Content modeling primer

A content model reflects the structure of your content. Each type of content requires an individual model. A model is separate from its format and only describes the content itself, not the way in which it will be delivered.

Modeling begins with analysis; analysis of your customer needs and existing content if you have it.

Let’s say for example it is your job to develop a content strategy for a new consumer electronic product. You begin with your analysis of the customer and the content you want to make sure they receive. What kind of content do they need?

• Description
• Feature
• Benefits
• Specification
• Support

When you look at this list, each one of them could be a model. Let’s take Feature and look at in more detail. At the top level, Feature contains:

• Feature summary statement
• Feature description
• Key points
• Supporting information
• Related links

If we were to look at this in even more detail, we would probably break out the related links as a structure. I expect that we’ll need related links on all of the content types so it’s probably a model on its own.

Related links aren’t the only place we could be more detailed.
Let’s dive down a level in Key points. Key points could consist of:

• Key points
• Lead in phrase
• Key point
• Point
• Detail

So now, this is really detailed. Do we really need this level of detail in the model? Maybe, maybe not. Two reasons you might want to have this level of detail are to support the writing and to support responsive design.

Writing Guidelines

Let’s start with the writing guidelines. Our guidelines could go something like this:

Lead in phrase. A common introductory phrase for a series of key point(s).

Point. Includes one specific statement and allows a quick scan for key information. Ideally one to three words, a maximum of five words and not to exceed 40 characters. A Key Point can stand alone or can be followed by Key Point Detail. Include a minimum of three Key Points. Contains the details about the individual feature or capability. For example, it could contain a description of one technical aspect or the physical dimensions of the offering. Each feature/capability is a single “what”, “where”, “how” or “when” and does not discuss benefits. Each Key Point can be a short paragraph or in a list. Keep the language factual, full of impact and easy to scan.

Detail. Supplies additional detail for the Point, is no longer than a sentence and is usually a sentence fragment. If you use Detail for one Point, you must use Detail for all Points to maintain parallel structure.

Content separate from format

A key concept in content modeling is that content is separate from format. As a content strategist you need to have some idea of where your content will eventually end up but not when you are doing your modeling. So our Feature description can be a web page. But what about if we want to view this on a smartphone (mobile device)? Sure we could display it as the same web page, but then the reader has to do a lot of pinching to shrink the viewable area and reverse pinch (expand) the viewable area. Wouldn’t it be a whole lot nicer if they didn’t have to do this? So let’s say that when viewed they just see the points and can click to get more or expand the content in place. A whole lot better user experience.

Do you need XML?

OK, so here’s that ugly word that everyone is talking about, XML. If your company was using XML instead of traditional HTML, they could display the content differently depending upon the device. Why? Because XML knows what type of content it is (semantic tags) and has a set of rules that define what it should do with it to display it correctly. And where did those rules come from? Most likely you as a content strategist working with a designer have defined those rules. Do you need to know how to create those rules in XML? No. You need a technical person to do that, but you provide the specification for functionality (rules). Could this be done if you weren’t using XML? Maybe, but it would be lot more work from a software perspective.

Simplest case you use your models to define what you need, how the content should be structured, and how best to write it. Your models can be implemented in a form or template. If you go multiplatform in the future, your content will be ready!

This has been very brief. I will describe this in much more detail in the upcoming second edition of Managing Enterprise Content, which I have to get back to writing now