Create your content model
Creating a quality content model is a key to a successful content strategy yet knowing all the ins and outs is far from easy. This article will take you through the steps of modeling content one by one. If you follow this guide, you'll get a suitable content model for your business or at least a good basis for one.
Table of contents
Primarily, content modeling answers the question, “What relationships does my content have?” However, different companies will have different answers.
In the coffee industry, each coffee has a preferred brewing method. In the insurance industry, articles should increase insurance sales. Similarly, content that relates together should be modeled that way too.
This is not the beginning of the content modeling journey
If you just got here and you're not sure what content modeling is or why you should invest your time into it, we recommend reading What is content modeling first.
During the whole process of this tutorial, bear in mind the following:
- Content modeling can be a very large topic. These steps summarize our experience at Kentico and focus on the main points to get the proper result, yet not going into all details that different businesses might have.
- No general advice can work in all cases. Sometimes, going against generally accepted advice is the best approach. So, don't hesitate to decide differently than advised here and there if you strongly believe so. (Or, send us an email and we may look at it.)
It's essential that the content model is approved by all stakeholders. That's why we recommend involving at least one stakeholder from each department in all steps of this article.
- Involve all internal stakeholders to collect current content and to design a basic diagram with your favorite tools. Start small with your core content types and expand it as you go.
- Start listing your content type elements with any enforced validation rules, and mark any repeating elements which might be grouped into its own content type or content type snippet.
- Map out relationships among all content types, and add metadata for personalization, tagging, etc.
Now, let's get to it!
Continue to 1. List your core content types by clicking the Continue to next step button:
1. List your core content types
First, put together those content types that are the center of your content production. Go through all your content repositories – your websites, apps, all types of storage for files like PDFs or Word documents. Group them based on their purpose.
Feel free to use any suitable tool – a whiteboard, software for diagrams (for example, diagrams.netOpens in a new window), a spreadsheet, or even mind mapping software. You can also use just a piece of paper, yet you'll often redraw parts of the diagrams which creates more work.
In this tutorial, the examples are from our example project Safelife, a fictional insurance company. You may have testimonials directly on your website or as a bunch of PDFs on a shared drive in such a company. If so, draw a rectangle representing a content type labeled Testimonial.
Like that, go through all your content and draw a rectangle with a relevant label for each content that you find useful or with purposes.
Include both information that will be displayed on a website or through a different channel (for example, Blog post) and information that serves an internal purpose (for example, Global brand identity).
2. Add structure to the content types
Once you noted your core content types, extend each content type so that it also contains the content type’s structure. Look for elements that somehow define the content type and what the content type consists of. Add those elements to the content type’s rectangle.
Going back to the testimonial example from the previous step, such a content type could have elements like a Tagline, Quote, Author, and Author’s headshot. Or, looking into blog posts, they usually consist of a Title, Lead paragraph, Content, and an Author. But there can also be other elements in the structure, such as related blog posts or CTAs.
In this part, try to focus on the actual content. You don't need to include metadata, which will be described in the next chapters. Do not include elements used for formatting purposes, such as color, font, or layout type.
If you're already familiar with Kontent's different elements, note also the element's type. If not, read What is content modeling.
3. Change visual content types into semantic content types
After defining the content types and their elements, think about each content type you created. The goal is to evaluate whether the content type expresses the essence of what it represents instead of how it is represented.
For example, a content type called Page focuses on the fact that the content in it is going to be represented as webpages. However, if you introduce a mobile app, that will no longer be true and your content model will become obsolete. Instead, use a content type called Article to ensure that you think about the content from the point of view of its meaning.
On the other hand, some parts of the content model will always relate to their appearance. A content type called Landing page will usually end up being landing pages, no matter what medium you’ll be using. In that case, calling them a “page” is not a problem.
Is page a bad word?
No, it isn't. It just limits content to be used within a specific channel, a website in this case. Moreover, the word page will be used for navigation later on.
In the example content model below, you can also notice a highlighted section that will later serve for dynamic elements on the website. Besides the Landing page, there's the Navigation item that will serve for building a website page tree and for a sitemap. Navigation will be further described in the next chapters.
There are also four content types that will be used by the website to display widgets. You configure what they should contain and your developers implement their appearance so there are no limits, yet you can limit what content creators can fill in to ensure visual unity.
As mentioned in the diagram, the content types in the highlighted section are there to be used as components or pages for one use case. One widget can be reused in multiple places, yet usually with the same purpose. That's why you shouldn't store reusable content in those.
4. Reuse what’s reusable
You might notice that some content types contain similar or even the same elements.
In the example content model, there are several places where repeated content is:
- Blog post contains an author, which will be repeated (one author usually writes many articles).
- Images are usually used in multiple places with the same title and alternative text.
The main criterion is if the set of values for the element overlap. In that case, consider creating a separate content type representing the given set. On the example website, there is also a listing of all authors and a filter set up so it makes even more sense to create a separate content type for them.
Images and other assets are usually distributed with additional information. It can be a title, an alternative text, or even tags. That's why it's suitable to create a content type called Asset that will contain the asset itself along with all the necessary information. The biggest advantage is that this implementation can be later easily extended.
Again, in the example content model, there are several places with repeated elements:
- All widget types contain How widgets work, Title, and Subtitle.
- Article and Blog post contain Title or Body copy.
If the set of elements is only repeating without sharing the given set of content, consider using content type snippets. They allow you to create a repeating set of elements for multiple content types.
The widgets in the example are suitable to be used as a content type snippet as the content in them won't be the same but they are going to be always used together as all widgets relate to each other.
On the other hand, you can see that for Article and Blog post, the Title and Body copy stayed separate. Even one element can be created as a content type snippet but in this case, we decided to keep them separate as the elements could later change independently of each other.
5. Connect the content types with relationships
One of the first sentences in this tutorial said that content models are mainly about relationships among content types. This step will be mainly about noting them in the diagram.
If you already know database relationships, content model relationships are practically the same.
Types of relationships
It's important to specify types of relationships in your diagram as they are modeled differently later. Their type also depends on the purpose of the connection. There are three types of relationships:
- 1:1 (one-to-one) – means that one content item relates to exactly one other content item. It usually applies for one-time content that is not reusable or for categorization and other metadata. For example:
- Each department must have a manager, and each manager can manage one department only.
- Every person in most countries has one ID (e.g., Social Security number), and every ID has exactly one person assigned to it.
- In content modeling, you may want to have each article to have a call to action. That call to action is used in one article only.
- 1:N (one-to-many) – means that one content item can relate to multiple content items, yet the other content items relate in that relationship to that one content item only. For example:
- One account manager takes care of multiple accounts, yet every account always has one account manager.
- A car brand (Ford) has multiple models (Mustang, Fiesta) but every model (Mustang) is produced under one brand (Ford).
- As a content modeling example, when a navigation menu is expandable, a menu item has multiple sub-items, yet one sub-item always belongs only to one menu item.
- Going to the most common use-case, related articles would also be an example of the 1:N relationship. An article is linked to multiple articles, yet in that relationship, the related articles are linked to that one article.
- M:N (many-to-many) – means that multiple content items can relate to multiple other items and vice versa. To use it in content modeling, these relationships require an additional content type used for purposes of the connection. For example:
- Multiple authors can write multiple books. So, one or more authors can write a book, and one or more books can be written by one author or a group of authors.
- Multiple doctors have multiple patients. So, one or more doctors have examined multiple patients, and multiple patients have been examined by multiple doctors.
- In content modeling, if you want to categorize multiple articles and blog posts together because they all fit within a topic, you’ll create the M:N relationship.
Is the relationship for categorization 1:N or M:N?
As examples in the list above, there are related articles as 1:N and blog posts on a topic as M:N. These two relationships are very similar when people are talking, yet for computers, those are two different things.
Related articles usually don’t share the same group. Article A is related to articles B and C, but article B is related to A and D, not C. In this case, the relationship is 1:N as each (1) article has multiple (N) related articles. So, four articles would have their own 1:N relationship each.
However, if there are articles on a specific topic, all are related to each other within one group, which is represented as an M:N relationship. Article A is on the same topic as B, C, and D while article B is on the same topic as A, C, and D. The relationship is the same for all articles on the same topic.
Opposed to 1:N relationships, the great thing about M:N relationships is their flexibility. You can add them to any content model pretty much at any time, which means less content model re-designs in the future. The downside might be the required mind shift and the need for better content creator training.
Now, there’s a question of whether the relationships are going to be implemented as content types or taxonomies in your content model. Don’t think about it now, the next step will describe this part of the process.
Add relationships to the diagram
Draw relationships in your diagram as lines connecting the element with the related content type. Moreover, every relationship can have a limitation. For example, the example content model can have up to three related articles. Mark these limitations to the diagram as well.
6. Establish hierarchies for navigation
Whether your content is displayed to your visitors through a website, mobile app, or a different channel, it typically has some sort of hierarchy whose purpose is navigation. For example, websites have page trees – there's a home page leading to article listing, a contact page, etc. The article listing then leads to an article view.
This structure is also a relationship that you've added to your diagram in the previous chapter. To build such a structure, you need to create a relationship between each level of your hierarchy.
Separate content from navigation
One of the reasons why headless CMSs become popular is the fact that the content created is reusable among different channels such as websites, mobile apps, smartwatch apps, or chatbots. Creating quality content isn't trivial so if you create it, you most likely want to present it effectively on different devices.
To get the flexibility in using the same content on different devices, create a separate content type for the actual content, and then create a content type for navigation in each of your channels. In Web Spotlight, there are already Home and Page content types created for your website navigation.
A simple model for a simple website
If your Kontent project is going to be used just for a website, where content is tightly connected to its web presentation, you can use the Page content type for your content to avoid making your content model overly complex. However, this approach is suitable only for microsites and similar smaller, single-purpose websites.
Link content with navigation
So that your website or mobile app knows what content to display within a specific location, connect your navigation items to your content. Create a Linked items element in the navigation item's content type. In its items, you'll use the element to link the actual content.
You can connect it the other way around if it's more comfortable for content creators in your case. However, the first approach proves to be better in most cases.
If you use Web Spotlight, use the Subpages element instead of the Linked items element.
Adjust the diagram for your navigation
If your project represents a website, this adjustment will most likely require more changes to the current state of your content model diagram. In the sample website, the flow of the relationship changed. Instead of the Articles and Landing pages linking to Navigation items (through the SEO metadata snippet), the Navigation item was renamed to Page and it now leads to either an Article or a Landing page.
See the diagram on https://app.diagrams.net?lightbox=1&nav=1#Uhttps%3A%2F%2Fraw.githubusercontent.com%2FKenticoDocs%2Fkontent-docs-diagrams%2Fmaster%2Fcontent_modeling%2Fsafelife_tutorials%2Fsafelife_navigation.drawio
It expresses the idea behind the web structure. A website contains a page tree. The page tree contains pages. Pages can be articles, landing pages, or pages with another purpose. Also, Articles and Landing pages contain only the actual content this way.
If your project doesn't contain a website, or you're not using Web Spotlight, use a Linked items element instead of the Subpages element. You can also keep the Navigation item or any name that makes sense for your use case.
7. Think about taxonomies
Until now, only content types have been mentioned. Yet, there are also taxonomies, a different part of the content model that might be sometimes more suitable than a content type. To identify them, look for content types representing lists like categories, tags, segments, or any enumeration whose values you want to assign to other content items. You may also imagine these as a drop-down picker.
Dive deeper into taxonomies
If you're completely new to taxonomies, go through our crash course on taxonomies where you'll learn about what a taxonomy is, what it's useful for, and how you can start using it.
Divide lists into taxonomies and content types
When you selected the content types that serve as categories, decide for each whether the content type should stay a content type or it should be taxonomy and you need to change it accordingly.
Taxonomies and content types are suitable for different use cases. You can usually use taxonomies when you need an internal, invisible relationship between objects (for example, a persona or customer journey metadata) while content types are better for external, visible relationships observable on the front end (for example, blog authors or article CTAs).
Use content types if you want to:
- Localize the values and you want to display them on your multilingual website, app or other media
- Let your content creators add new entries to the list of values
On the other hand, use taxonomies if you want to:
- Be able to filter based on the values in the content list in Kontent
- Represent internal (invisible) relationships
- Prevent content creators from altering the list
Global search for content items is available as well, but filters are only available for taxonomy values.
Use content types and items for lists
You can model content types that you see as a 1:N relationship in a straightforward way. If content type A (e.g., Blog post) links to content type B (e.g., Author):
- For creating the options, create content items based on content type B (Author). Each item will represent one option.
- Add a linked items element to content type A (Blog post) that will be limited to content type B (Author).
- If suitable, limit the element so that content creators can add a specific number of options only.
- Create a content item of content type A (Blog post), and link the related content items of type B (Author) to it to create their relationship.
If you want content type A to link again to content type A (for example, for related articles), start with step 2 directly.
For a limited (often curated) number of content items, link them vice versa. That means, link the content items of type A (Blog post) from content items of type B (Author). For example, for the top blog posts of this week, you’ll have an item called Top blog posts of this week, which will link to each promoted blog post.
For M:N relationships, this approach is recommended as well because it’s easier to manage. Add a third content type that will link all relevant items of the other two content types.
See the diagram below to check how both cases are modeled in the Safelife demo project:
- Blog categories is an example of a 1:N relationship with preset options.
- Author is an example of a 1:N relationship with changeable options.
- Navigation item is an example of a 1:N relationship with itself.
- Topic is an example of Blog post's and Article's M:N relationship.
See the diagram on https://app.diagrams.net?lightbox=1&nav=1#Uhttps%3A%2F%2Fraw.githubusercontent.com%2FKenticoDocs%2Fkontent-docs-diagrams%2Fmaster%2Fcontent_modeling%2Fsafelife_tutorials%2Fsafelife_taxonomies.drawio
Now is the time to put the content model into Kontent
If you have created the content model on a physical medium or in a diagram software, now is the time to convert it into Kontent. To do that, go to Kontent and add the necessary content types, content type snippets, taxonomies, and set up everything else related to the content model, like the limitations of each element.
8. Write down the metadata
Preparing personalized customer journeys can't be done randomly. When you go to your favorite smaller shop on the corner where you go every morning, the owner or employees there most probably know you. The better ones even know your name, maybe even allergies, personality, etc. In smaller, face-to-face shops, this is how personalized customer journeys are done. But how can you do this in your online business?
Personalize content online
For larger, online companies, personalization depends on quality metadata. Speaking content, do not start designing your metadata based on existing navigation or categorization in existing projects. Take a step back and have a look at your customer journeys at first and focus on categories and navigation at the end. Map your content types to your customer journey steps and explore how to effectively target these steps with your content.
The most basic form of personalization can be set up by adding a Persona element to the content types aimed at specific personas. In the example, it's the CTA content type. For the Article, Blog post, and Widget - Curated content types, the example enables authors to choose from different Voice & tone option that later changes the webpage layout for the viewers.
See the diagram on https://app.diagrams.net?lightbox=1&nav=1#Uhttps%3A%2F%2Fraw.githubusercontent.com%2FKenticoDocs%2Fkontent-docs-diagrams%2Fmaster%2Fcontent_modeling%2Fsafelife_tutorials%2Fsafelife_metadata.drawio
A different way to implement personas is to tag content items and specify which tags are typical for a given persona in a separate content item. You can also add buyer decisionOpens in a new window stages as a taxonomy. Those should cover your basic needs, but there might be more depending on how targeted you want to be.
Consider the internal point of view as well
It doesn’t matter how many metadata elements you have if no one will end up using them. The process of adding content and metadata should be logical and straightforward:
- Limit what content types can be used where.
- Set up guidelines for all nontrivial or important elements – use screenshots to show how an element or content type will be shown on various frontends, and describe the voice and tone.
- Set up automated tools for keyword extractionOpens in a new window where possible to minimize manual work. This approach is great for SEO-related elements represented by content type snippets.
- If you notice other elements being used in the same content types as the SEO metadata, consider moving them into the snippet as well. Those elements could be taxonomies for website navigation, menus, URL slugs, etc.
Advantages of using content type snippets
Grouping elements into content type snippets allows you to extend the list of elements in one place and gives your front end developers a unified data set for all content types. This helps to build a highly flexible content model.
Now, you have a content model ready to be used in production. If you want to go through the content model used as the Safelife example, take a look at the final content model diagram:
See the diagram on https://app.diagrams.net?lightbox=1&nav=1#Uhttps%3A%2F%2Fraw.githubusercontent.com%2FKenticoDocs%2Fkontent-docs-diagrams%2Fmaster%2Fcontent_modeling%2Fsafelife_tutorials%2Fsafelife_final.drawio
Alternatively, you can also browse through the websiteOpens in a new window. Please note that not everything was implemented in there for the sake of simplicity.
The next step is to prepare your content model to go live!Go live with your content model