Content Modelling: A Master Skill

APRIL 24, 2012

Go to article

by RACHEL LOVINGER

• Published in: Content Strategy
• Discuss this article » | Share this article »

In “Tinker, Tailor, Content Strategist,” which runs concurrently in this issue, I asked you about content strategy master skills, which hardly seems fair if I don’t share one of my own favorites. More and more I find that the content model is one of the most important content strategy tools at my disposal. It allows me to represent content in a way that translates the intention, stakeholder needs, and functional requirements from the user experience design into something that can be built by developers implementing a CMS. The content model helps me make sure that the content vision becomes a reality.

What is a content model?

A content model documents all the different types of content you will have for a given project. It contains detailed definitions of each content type’s elements and their relationships to each other. You can capture a high-level version in an org chart-style diagram, or use a spreadsheet to capture a more detailed version. The level of detail in the model is determined by the purposes you need it to serve.

A simple, high-level content model

The high-level model shown here depicts some common content types of a music website and how they’d relate to each other. Items in the sales chart would link to pages about the relevant songs, artists, and albums listed. The album, artist, and song pages would also be linked to each other. This model can be used to validate the concept with stakeholders, and helps IAs and designers start thinking about the implications for the flow of the site.

Most of the time, however, you’ll need a more detailed content model that breaks down each content type into its components, and provides information such as the format in which you expect each attribute. In the example above, a more detailed model—showing the breakdown of information captured about an album, artist or song—would be developed to inform the design of the pages themselves and help configure the CMS. It will also eventually be useful in training the content creators.



Why is a content model important?

The content model both influences and is influenced by the work of several other disciplines. A content model helps clarify requirements and encourages collaboration between the designers, the developers creating the CMS, and the content creators.

For information architects and designers – The content model helps information architects and designers make sure that the page designs accommodate all the content types for the site and provides guidance on the bits of text and media that will be available for the page. At the same time, the content model needs to support the content, layout, and functionality portrayed in the designs. If captions are included in the layout, that must be captured in the model for an Image. If events must be sorted by date on a calendar, then Date has to be captured in a separate field and it has to be sortable data, not just text. Depending on the complexity of the site, a high-to-medium level of detail is usually sufficient for designers.

For developers – The content model helps developers understand content needs and requirements as they configure the CMS. Given the many types of CMS, there are many ways to accomplish the same effect. If the content model indicates something that isn’t easily accomplished by a given CMS, it helps the developers adjust their approach to create the desired result in a way that’s compatible with the way the CMS works. Developers will need a greater level of detail in the content model. If the content strategist doesn’t provide them, the developers will interpret content needs and make up the details themselves. And they may not be in a position to keep in mind all the design requirements, as well as the needs of the content producers who will use the system.

For content authors and producers – The content model gives content authors and producers guidelines on what content to write or create and how to enter it into the CMS. Although they aren’t generally part of the content modeling process, it’s important to keep this audience in mind because they’ll be the ones working with the CMS each day. For their sake, try to keep the model intuitive, be consistent where there are similarities, and keep redundant activities to a minimum. Depending on how you set up the content model, you can make it easy for them to get their work done, or you can make them dread having to use the system.

How do you create a content model?

There are three main things to consider:

1. The assembly model: The way content creators will put individual content items together to make webpages, campaigns, documents, or other content products.
2. The content types: The various configurations of content that are distinct enough to be unique types in the system.
3. The content attributes: The content and metadata elements that make up each type, including how they relate to each other.

THE ASSEMBLY MODEL

It’s important to understand that most CMSs have a bias. They’re often designed around a certain “unit” of content and that’s what they’re optimized to create. For blog applications, the unit is a post. For Sharepoint, a unit is a document. For most web content management tools a unit is a webpage, even though we’re more likely to be making dynamic sites that use (and reuse) content in a variety of configurations.

During one conversation at the start of a project using FatWire, I started sketching how the elements of a page could be assembled. One of the developers immediately observed, “That’s a very Interwoven way of doing things. We can’t do that in FatWire.” Interwoven is a line of CMS products that allow you to identify a repeatable group of attributes within a content item. For example, an individual FAQ item could be composed of a question, an answer, an optional image, and an optional link. When creating the page, the content creator can “replicate” that entire group of attributes to create as many FAQ items as needed to complete the page. FatWire doesn’t allow that kind of open-ended replication of groups of attributes. You must either specify the maximum number of fields you need for all of the question-answer sets (and the user can leave some of them blank), or you must make the question-answer set its own separate content type and then assemble the sets into a list on the FAQ page.

To make these decisions, you need to consider how modular your content needs to be. Some types of content, such as a press release, may be fairly self-contained. Each instance of Press Release will create one page. In other cases, you’ll have pages made up of many different reusable content modules collected to create the whole. In the FAQ example, if you want to be able to use certain questions on multiple FAQ pages, then it makes sense to have each question-answer set be its own content item. Then they could be manually gathered into lists, or they could be tagged with terms to be dynamically assembled into FAQs by topic.

Some other things to consider when thinking about the assembly model:

• How structured does the content need to be? Do you need to capture specific, uniquely identifiable data that can be used to sort or filter the content (for example, date, price, rating, author, or location)?
• How flexible does the content need to be? Can you predict what the elements of a page will be, how many and in what order? Or do you need to support an open structure with the ability to add varying numbers of various content elements to any part of the page?
• How reusable does the content need to be? Can you make the reusable parts separate so that they can be shared across different pages of the site?
• How tolerant are your content creators of laborious processes? If you ask them to take a lot of unstructured content and break it into dozens of distinct data fields, are they going to have the time to do it? If you’re lucky, maybe they’re already used to doing that kind of work, but try to avoid asking them to break up the content if it serves no functional purpose, because this can be very time-consuming.

Don’t worry too much about getting precise answers to these questions at this initial stage. This information will help guide decisions in the next two steps. So even if you can’t get consensus on the answers, just having the questions will help shape your thinking and discussions for the rest of the task.

THE CONTENT TYPES

Questions about how structured the content needs to be will help you determine what constitutes a distinct content type. If the content doesn’t need to be structured, you can have one basic content type and put whatever you need to in it. This is the premise behind a blog post. Very flexible but very unstructured.

More likely, you will want to create at least some structured content types. Then you need to abstract the kinds of content you’re creating and look for patterns. Consider the elements that make up a piece of content and see how many attributes they have in common. For example, a Recipe is clearly quite different from a Slideshow. But is a Band Profile close enough to an Actor Profile that they can be two flavors of the same underlying Profile type?

There are other reasons to make something a separate type of content:

1. Distinct, reusable elements. You might decide to create an Author content type that contains the name, bio and photo of each author. These can then be associated with any piece of content that person writes.
2. Functional requirements. A Video might be a different type of content because the presentation layer needs to be prepared to invoke the video player.
3. Organizational requirements. A Press Release may be very similar to a general Content Page, but only the Press Release is going to appear in an automatically aggregated Newsroom. It’s easier for these to be filtered out if they’re a unique type of content.

The lines can get fuzzy, especially because some elements within the type will always be optional. Sometimes it comes down to a question of “How many differences does it take before something is a completely different thing?” When you have a situation that’s too close to call it’s probably a good idea to collaborate with your tech team and business analyst or functional analyst to come up with the best approach.

THE CONTENT ATTRIBUTES

In the last step, you’ll identify each different element of each content type. This includes both the content that you can see on the page, and the metadata, which you don’t see. It also includes relationships to other content types. For example, if you create a separate Author content type, you will need to indicate that a Review can have an Author associated with it.

Some elements will be obvious—your press release has a title, maybe a subtitle, an optional image, and body text. But determining which pieces of information need to be captured in separate fields can be a challenge in some cases. Consider the following:

• Layout Do some things need to be displayed in a completely different style, or on varying places on the page? You should avoid having markup and styling stored with the content, so ideally each element that needs to be displayed differently should be in its own field. For example, you could just make the subtitle part of the body text and ask your editors to bold it, but how well is that going to work with the RSS feed or on a mobile device?
• Reuse Again, a separate field of data can be pulled out and used independently of the rest of the page, but not if it’s all part of one big body text.
• Sorting and filtering If you want to be able to sort content by date, or filter content that pertains to a particular city, then these pieces of information have to be in a field by themselves so that they can be used to sort and filter.

Once you’ve determined what the different elements are, you’ll also need to capture information such as what format each element should be in and whether or not it’s required. For example, if you want to sort a certain type of content by date, then every instance needs to have a date, and you can’t have some dates entered as mm/dd/yyyy and some entered as dd/mm/yyyy. Again, coordinate with your tech team to make sure you’re providing them the information that they need to configure the system. And coordinate with your business/functional analyst to make sure that your recommendations are aligned.

CONTENT MODEL DOCUMENTATION

Since the content model serves different audiences, at several different stages of the project, treat it as a living document. It’s never really complete—you just stop updating it when the project is over. As such, it’s better as a working document than a finished deliverable. Over the lifecycle of a content model many people will have input, and it’s even possible that different people will own it at different stages. In most of my projects I’ve handed off the content model to either a functional analyst or developer at some point.

Mainly, the project team will use the content model internally. I’ve rarely had stakeholders who wanted to review an in-progress content model. When they have, they’ve had little to say about it. What they really want is a CMS that meets their design, tech, and business needs, and also serves the people who will have to use it. The content model helps the team to make that happen.

On occasion, you may need to ask stakeholders for input or decisions. It may be more useful to pull out the salient details and present them separately. This way they can focus on the question at hand rather than trying to understand the whole of the content model.

If you must also create CMS training or content production guidelines, the content model will serve as a useful starting point. You can easily excerpt information as needed and reformat it into a more user-friendly document. Though we might strive for a well-configured CMS that’s intuitive and easy to use, the reality of the implementation is almost always more complicated than that. Providing proper guidance to the CMS users could make the difference between the project being perceived as a success or as a serious mess.

Conclusion

A content model is a powerful tool for fostering communication and aligning efforts between UX design, editorial, and technical resources on a project. By clearly defining the assembly model, the content types, and the content attributes, we can help make sure that the envisioned content strategy becomes a reality for the content creators. In my recent projects, I find that content modeling is more and more in demand. It’s a valuable skill for any content strategist, especially those that strive for mastery. 

• Illustration by Kevin Cornell