A client once looked at the content model I was working on and described it as an ‘arcane discipline’. I replay that moment in my head a lot: mulling over whether they were totally right or totally wrong, and how I could have made the value clearer. Content modelling and structured content are transformational, but it feels like organisations miss out on the benefits because they’re seen as esoteric and complicated.
So I’ve written a guide to content models and structured content. The idea is to make the concepts and benefits clear and act as a jumping off point for people who want to find out more.
I can’t write about content models without saying that I owe a lot of my understanding to Carrie Hane and Mike Atherton’s book, Designing Connected Content. If you want to go in-depth, I really recommend reading this.
What is a content model?
We’re going to start with a definition:
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.
Let’s break that down and make it even simpler:
- A content model is a diagram and/or a spreadsheet
- It lists all the different content types you have
- It breaks each of those content types down to give you list of the individual attributes or elements it’s made of
- It maps out how those elements relate to each other
The real game-changer: structured content
But a content model is just a means to an end, a deliverable that you need to create to get to the real goal: structured content.
Structured content is content that is broken into its smallest reasonable pieces, which are explicitly organized and classified so that computers and humans can understand them. This content can be treated as data. Each of the smallest reasonable pieces provide explicit information for machines to understand and use in all kinds of ways.
Again, let’s break that definition down:
- Structured content means thinking about content as data
- The structure comes from breaking content down into individual attributes or elements
- Those individual attributes are organised and classified
And structured content is a game-changer. In the same article, Carrie writes:
“Structured content enables you to do more with the content you already have — without hiring more people, investing more time, or spending more money. Your team, your company, and your audience all benefit. Content becomes easier to find, allows you to innovate and adapt faster, and helps your team work more efficiently. Structured content cannot be hyped enough.”
She’s absolutely spot-on. Adopting structured content (by designing and implementing a content model) unlocks a whole range of benefits:
1. Reusability: the biggie
For me, reusability is the biggest benefit of a structured approach to content.
Thinking about content as data, as content types and attributes, means you have to stop thinking about content as pages. And that’s a good thing. Pages are solid, single-use pieces of content. With structured content, you build a page out of content types that you can reuse elsewhere.
Here’s an example to make it more tangible. Imagine you’re creating content about an event:
- Unstructured approach: in your content management system (CMS) you create a page, open the text editor and copy and paste the information about the event. You’ve got your page, but it’s single use.
- Structured approach: your content type is predefined in your CMS, and you build it from the individual attributes (chunks of information) users need: event name, date, description, etc. You do so by filling in filling in fields for each attribute. You can reuse those attributes elsewhere — for example, by pulling them into a listing card for the event. And you have a reusable content type for the next time you put on an event.
This illustration shows what it can look like to switch from thinking about pages to thinking about attributes:
On the left the mock up shows a page of content about an event – it’s been created as one big block of information.
On the right, we see the same content, but it has been broken down into the individual attributes, like the name of the event, the date, start time, etc.
2. Consistency and accuracy
You can probably see now how the reusability of structured content will help with consistency and accuracy. The content types act as a template, so your content will be more consistent and complete.
And it helps with accuracy, too — if information changes, you’ll either know exactly where it’s being used, or change it in one place and it will update everywhere.
Years ago I worked at a price comparison site, and we had a call-to-action based on the average amount you could save by switching energy supplier. When I started, this call-to-action was on hundreds of pages. When the average changed — which it did often — I had to go and manually find and change each mention. Until I realised I could create one instance of the call-to-action and embed that on multiple pages. This saved hours and reduced the risk of having out-of-date information on the site. This is just one example of how simple it can be to do some very basic structured content. Other things that you might be able to tackle in a similar way include contact information and opening hours.
3. Efficiency and cost savings
Having so much structure makes it easier to create, update, and manage content, which saves time and money.
All that structure can make it easier for machines and users alike to find your content and understand what it’s about.
It can help users by making it easier to filter or sort content in a range of different ways. To go back to our event example, with structured content, the user could search events by date and age group to find one that’s suitable.
You can also integrate structured data, like Schema.org markup, which helps search engines understand your content and can increase your organic search visibility. Again, in our events example, using the Schema event markup would mean having results like these:
How to create a content model
In this guide, I’m going to provide a quick overview of some of the stages of creating a content model. For an in-depth look at the process, read this article by Carrie Hane, or the Designing Connected Content book I mentioned earlier.
1. Create a domain model
The first step is to create your domain model. The domain is the subject matter, the topic, the area, the activity that you’re creating the content model for.
In a domain model, you’re looking to list all the concepts that relate to the subject area. Those concepts could be real (like a place) or abstract (like a topic). You will also need to capture the relationships and connections between those things. For example, an event (concept) takes place at a venue (concept) and is about a topic (concept).
The example below is a snapshot from a domain model I created for a client — events were one small part of the overall domain in this instance – but it should give you an idea of what you’re looking for.
An illustration of a domain model for the subject ‘Event’. It’s mind map, with ‘Event’ at the centre, and related concepts like Session. Person, Series, Season, Topic, Tickets, Venue spidering out from it. The related concepts are all joined by lines, with text to describe the relationship. For example, Event is connected to Venue with the description’ Takes place at’. The lines also have a key and different marking to explain if they are a ‘ one-to-one’, ‘one-to-many’, ‘many to many’, or ‘optional’ relationship.
Most people really enjoy the experience of creating domain maps, in my experience, because it’s a visual process and has just the right level of challenge to get the brain ticking.
2. Define your content types
Once you have your domain map, you need to pick the concepts from it that will become content types. Remember that a content type is a template you use to create multiple pieces of content that have the same purpose and structure. So you need to pick the concepts where you’d actually want to have a reusable template, and where the content could stand alone.
For example, from the event domain model, I created content types for: event, venue, and person. They were all things that I could reuse for multiple instances/entities and that could stand on their own. I did not create content types for the event description, or start date and time, because those things would only make sense in the context of an event.
You should also capture the relationships between your content types, just like you did in your domain model. For example, an event takes place at a venue, and a person speaks at or hosts an event.
One thing to look out for with both your domain model and your content type is entities/instances. These are things that are unique or specific, and you don’t want to include them. For example, the concept of a ‘venue’ belongs in your domain model and can be a content type. But you shouldn’t include a list of different venues, like hotel, motel, Holiday Inn, because they are specific instances of the concept ‘venue’. Similarly, you shouldn’t create content types for things like your ‘About us’ page, as this is a single entity, not a content type that you’ll repeat.
3. List your attributes
The illustration below shows content types and their attributes:
An illustration of content types and their content attributes. The ‘Event’ content type is made up of the following attributes:
There is line, marked ‘Takes place at’ connecting the event content type to the ‘Venue’ content type, which is made up of the following attributes:
- Street Address
- Post code
Now you can list out the attributes that make up your content type. Here, you need to get into the details of what information your user needs as part of each content type.
So to go back to our event example again, for the event content type, the attributes might be: event name, event description, event type, topic, start/end date, and time, speaker, etc.
4. Create a spreadsheet
For the final step, you can create a spreadsheet and add some extra details to help with the next phase of the implementation.
When I do this, I try to capture:
- Content types
- Description and purpose
- Data type (e.g. is it a date, a number, an email address, plain text, formatted text, etc)
- CMS field label
- An example of the copy
How to put a content model into practice
You should use the content model in your team on a day to day basis. Every time you create a piece of content, you should be following the relevant content type and capturing all the necessary attributes.
If you’re working on a new website, you might find that your content model is a really useful process to inform wireframing or creating initial designs. It’ll give your designers some very specific, structured information about what needs to be on the page.
But beyond that, you should also be aiming to integrate your content model with your CMS to fully realise the structured approach you’ve planned for. This is the step that means you can stop just dumping all the copy into the text editor in your CMS and start having individual fields for the different attributes. To achieve this, you’ll need to work very closely with your IT/dev team (and what you can do will depend a lot on what CMS you have).
- Content Modelling: A Master Skill, Rachel Lovinger
- Content Modeling: What It Is and How to Get Started, Carrie Hane
- A Content Model Is Not a Design System, Mike Wills
- The beginnings of a content model for future undergraduate study content, Lauren Tormey
- Structured Content 101, Carrie Hane
- The Benefits of Structured Content, Greg Dunlap
- An Alchemist’s Quest: Designing the Enterprise Content Model, Marie Girard
- From structured content to working front-end: just how fast can you go?, Chris Atherton
- Open and Structured Content Models Project