Cleve Gibbon

Content modelling captures the structure and meaning of content and expresses it within content models.  Content modelling is the process, where the content model is its main deliverable.  But you have start somewhere right.  The conceptual content model is that starting.  A simple and succinct way to represent structured content.

Conceptual Content Model

The conceptual content model is the first output from content modelling.  After some initial work identifying, naming and agreeing what content types are important within your problem domain, we pull them together into a conceptual content model:

A conceptual content model is a box and arrows representation of content types and their inter-relationships.

It is essential that content strategists, information architects and business stakeholders to engage with content modelling early on in the process.  Why? Because these are the people best positioned to find and classify content types that make sense for the business. They bring that understanding of why content needs to be structured in this way and not that way. These implicit rules about content are made explicit and baked into the content model from the outset.

Finding content types

Warning: Treat content types like gremlins.  They live in dark places, evasive by nature and cause serious damage to your projects.  Take the time to bring them into light.

Content types live in mission statements, project proposals, existing web sites, product documentation, people’s heads, customer call centres, partner forums, FAQs, technical communications, and so on.  Our mission is to find and tame them!

Take at look at the following description for an event at a trade show:

An event has a detailed program that a primary contact is responsible for organising. All events have a venue and their related articles used to reference additional event information.

Back in the early nineties, there was a technique used by object-oriented designers to find candidate objects for the system under development.  Software designers were typically gifted with concise business requirements that described the problem domain.  Object-oriented modelling would take those requirements as inputs and focusing on the nouns, mine out all candidate objects.

Now, by applying the same techniques to our event trade show, we find the following candidate content types for our conceptual content model:

An event has a detailed program that a primary contact is responsible for organising. All events have a venue and their related articles used to reference additional event information.

Not surprisingly, the above technique for finding objects didn’t work out all that well for object-oriented designers.  Who ever gets all the requirements up front? Not me.  Also, they are unlikely to be accurate, signed-off, or complete.

Instead, the world is messy and needs smart people to make sense of it all.  And that’s the hard part that we don’t cover here.  Sorry.  That’s why we need you.  To find those pesky content types. To name them. Challenge them.  Validate them.  Describe them. Structure them. Refine them.  Model them.  Advocate them.  Rinse and repeat.  That’s a whole lot of pain and suffering right there that we going dodge for now.  But that’s content modelling. Instead, let’s assume you’ve done all that hard work and have your candidate content types.  What then?

Update (Mar 2016): We’re not bad people.  We have created a workshop that talks to this content modelling for personalisation that helps you on your way.  Check out our events page for more details.

Drawing content models

Write the content types down.  Arrange them into a list and give each candidate content type a one line description.  Weed out duplicates (e.g. article, feature, post, story), misfits (e.g. astronaut, monkey), maybes (e.g. Newsletter could be useful at some point), but keeping your eye out for glaring omissions.  And don’t use plurals.

Dust off this refined list of content types, pick one, draw a box and label it clearly.  Then start drawing other boxes and lines until every content type is down and labelled.  Also, it’s sometimes useful to annotate how one content type relates another.  For example, in the case of Venue and Event, in that specific context, the Venue content type is the event location for an Event.  For Event and Article, we know that an event has related articles.  So annotations are useful for conveying additional meaning to the reader for generic terms like article within the context of a specific relationship between content types.

Congratulations.  We have a conceptual content model with five content types: Program, Event, Contact Article and Venue.

Back to event

So our Event has:

• Related articles
• An organiser
• An event location

At this stage, it is important to re-enforce the difference between a content model and content modelling. The two are not the same. A content model is a formal representation of structured content. A tangible deliverable resulting from the act of content modelling. The hard work we alluded to before and purposefully dodged is doing the content modelling. This involves numerous sessions, discussions, workshops, analysis, debates, testing, interviews, prototypes, role playing, web site reviews, and so on to find content types and bring forth meaningful relationships.  The fruits of our labour go into the content model that serves to capture the vocabulary and representation of content, so that we can to effectively communicate its structure and meaning to all interested parties. That’s super important.

Revising the content model

After another round of content modelling discussions with the event organisation company, we find out that they need to keep track of event speakers and their ever changing profiles. So we tweak the content model like so:

Design Content Model

With a conceptual content model in place, the next step is to elaborate further and produce a design content model. Again, this is not a content model for techies.  Not yet.  The design content model adds more details around the type of relationships between content types, the kinds of values that content type elements should hold (e.g. text, numbers, images), channel considerations (mobile, email, social), domain-specific challenges (e.g. localisation, targeting, SEO) around content, some assumptions about creating content items from content types, the lifecycle of content items, and so on.  From here on end, content gets even messier.  But at least it’s out in the open for all to see and understand.  And more importantly, we have the means to collaborate with a shared understanding of how bring more order to content chaos.

Wrapping up

I often get asked the question around where content models fit in relation to other key IA/UX deliverables such as content maps, taxonomy, metadata, task analysis, site maps, navigational schemes and the like. The short answer is that we still rely heavily on all of those things because they remain critical to our projects. Content models do not replace or displace them.  They complement existing IA/UX deliverables, particularly for larger, more involved projects, and help course correct to ensure that we are aligned around content.  Content models help connect and raise awareness of content within multi-disciplined teams.

Conceptual content models are an incredibly lightweight tool for communicating how content is structured. They depict the key content types and meaningful relationships that exist between them, to a broader and more influential, decision making audience. Don’t start out without one.

Next steps

Where next:

• Content Models
  • Conceptual Content Model (this page)
    
  • Design Content Model
  • Implementation Content Model
  • Design Guidelines for Content Models