Whether you are using Sitecore or a modern headless solution such as Kentico Kontent or Contentful, there’s a fundamental step you must get right – modeling your content. A content model documents all content types associated with a brand and defines the relationship between those content types.

Content modeling is a perfect exercise to understand the difference between data and presentation. Data should be viewed as the information about your organization that can be displayed and re-used anywhere – on a website, in an app, or through any other process designed to take raw data and schedule an import into a separate system. 

In this respect, we ideally don’t want presentation information in our data set. The cleaner and more standardized the data is, the easier it is to re-use it elsewhere without persnickety transforms. 

Presentation, on the other hand, should be viewed as taking that clean data and transforming it into a format suitable for the intended consumption, for example, adding markup for a website or RSS for an external feed. 

Where Do I Begin?

An excellent place to start is some logical analysis and thought into how the content you already have can essentially be broken down into standard, structural elements. Let’s take the simple example of a blog – below is a proposed content model for our blog object. 

Blog

Note above that the two fields in red are reference fields storing a pointer to one or many other object types, which could be modeled as below: 

Author

Tag

This simple example should show the relationships between the object types you are creating, as a blog has a reference to an author and references to multiple tags. 

In this way, both the Author and Tag objects are reusable. This sort of construct also allows easy querying. You can imagine a list of all blogs by a specific Author or all Blogs with specific Tags (related items). 

This is now you should NOT do it.

The advantages described above cannot be realized by storing the Author and Tags on the Blog object. Free text fields are notorious breeding grounds for misspelling. Same for the Tags, and since the Tag data is embedded in the Blog object, there is no way to manage and reuse your tags, resulting in duplicates and again misspellings. 

Key Takeaways 

• Every content model is unique and consists mainly of content types and similar elements.
• Creating a content model is a collaborative effort. The best results are achieved if all stakeholders are involved. Some good questions to get in front of the Stakeholders are: 
• 
  
  • What is the most critical piece of data that needs to be communicated?
  • What other data also needs to be communicated?
  • How will people find and interact with this content?
  • Will this data change very often or stay static over long periods?
  • What is the goal of communicating this data to the user? What action should they take now they have this data (i.e. sign up for your newsletter, share the information)
  • What is the workflow for creating new content, and which stakeholders need to see it before publishing?
• Having a content strategy, mapping out customer journeys and an audit of the existing content is the best place to start. 
• Creating a Content Model Diagram is a valuable process as tables don’t engage as well as a visual representation.

A visual diagram of our proposed Blog, Author, and Tags might well look something like this: 

The Golden Rules

• Get that page-based mentality out of the picture. It’s too easy to think about designing content models from a web-centric point of view. Ideally, your data should be 100% reusable in any system. Unfortunately, working with modern headless systems requires a conceptual reset of the data design process. 
• Give descriptions to fields to help content editors do it right. 
• Use constraints and validation on your fields where possible. Content editors can’t be relied on to do it right every time, so some guardrails are helpful. 
• Think reuse when breaking your data down into objects.
• Find the right balance between modularity and granularity. If an author has to create five new content objects just to create a single blog, you may have done it wrong, and as above, having everything on a single object is not great either. 

Hopefully, this will have given you a good start in understanding modeling. Konabos is hugely experienced in this design process, so reach out if we can help you design your best unique content model.