Why should you be considering a Content Model?

The benefits of Content Modelling for digital teams

If you are building a new digital solution on a traditional CMS, a hybrid headless DXP (like Xperience by Kentico), or a fully headless CMS (like Kontent.ai or Storyblok), Content Modelling is a practice you should consider for your team. Here are some simple reasons why:

• Map out data points for content in a visual way.
• Build a content structure that can grow with the solution.
• Begin building content structures before engaging designers.
• Define common language and terminology.

In simple terms, a Content Model should act as a reference point for the entire content structure of a business. It should evolve and improve as your content matures and it should be as reusable as possible. 

The structure of the information contained within website pages, articles, products, assets and documents should all be defined within your Content Model as well as the relationships between those pieces of information. 

A Content Model should be a collaborative activity involving, designers, content creators, developers and stakeholders. 

At Ridgeway, we found that having a Content Model in place allowed the team to quickly understand the data points within Content Types and the relationships between those Content Types. (Content Types are the pieces that make up a Content Model.). We were able to do this without having to consider how the actual pages of the content would look in terms of style and design, meaning we could move quickly to engage content creation.

The benefits of Content Models in commercial enterprises

We know how Content Modelling can help digital teams but what's the benefit for commercial business? Here is a short story illustrating how a Content Model can work for a fictional business: Ridge Clothing.

Ridge Clothing sell very nice outdoor clothing such as jackets and warm coats. They predominantly sell their clothing online via their eCommerce website and also via their network of trusted stockists around the UK.

Their flagship product is their Men's Versatile 3-in-1 Jacket.

We know what the jacket looks like, using the image above. But in a digital context, this jacket exists as a collection of information (data) including the image, name, sizes, price, descriptions and more. In order for Ridge Clothing to sell this item, they will need to have all of this information available so that their customers can make an informed decision to purchase.

Therefore we can also say the Men's Versatile 3-in-1 Jacket is represented in a way similar to this:

• Name: Men's Versatile 3-in-1 Jacket
• Image: versatile-jacket-green.jpg
• Price: £230.00
• Sale Price: £200.00
• Size: Small, Medium, Large, X-Large, XX-Large, XXX-Large
• Delivery: Standard
• Sale: Yes
• Category: Men's coats & jackets
• Features: Stay warm in the cold, keep dry in the wet - or both at once! The Men's Versatile 3-in-1 Jacket lets you choose just how much weather protection you get.
• Specifications: Outer: Waterproof, seam-sealed. Adjustable hood that stows in collar. Two hand pockets Inner: 100% polyester brushed fleece. Elastic binding at cuffs and hem.

The collection of this data would be described as a 'Product'. A product housed within a sub-category, which is housed within a category, which is in turn housed within the eCommerce area of the Ridge Clothing website. In Content Modelling terms we'd define this as a 'Product Content Type'.

The information listed above is only really scratching the surface in terms of the data we could leverage. If, for example, Ridge Clothing wanted to improve organic search performance by answering queries that surfaced in their product reviews, the Content Model could be extended to include this type of data. This would mean every product on their website can make use of this new data field and begin ranking for relevant questions raised by potential customers. A victory for the Ridge Clothing website!

The versatility of a well-constructed Content Model also means you'll be able to future proof your content for new channels and technologies. Because the Content Model is not linked to the presentation (design elements) of the content, it can move wherever the business needs to move. That may be re-platforming, or expanding into a new language or region.

If you'd like to know more about building a Content Model, either for a client or your own business, I've included some simple steps to get the ball rolling.

Building a Content Model

Prior to starting any Content Modelling, make sure you have a few things in place:

1. Project Goals - make sure the team is clear on what the project is aiming to achieve and what the outputs are.
2. Content Inventory - know where your content is and what state it is in. Is it within another system? Is new content stored within documents or spreadsheets?
3. Draft a Content Strategy Document - a doc outlining the responsibilities, priorities and expectations for the overall content of the business.
4. User Personas - know who your users are and how they use your content.
5. Read up - get your head around Content Modelling using Kontent.ai's Content Modelling hub. 
6. Collaborative tools - set your team up on a collaborative whiteboard tool such as Miro or Mural.

1. Collect & list your Content Types

Visit your Content Inventory, consult your team, and conduct a crawl of your current website. These are all activities that will help define the Content Types in use. Add your list of Content Types to your whiteboard as simple labels.

2. Add structure to your Content Types

Find active examples of your Content Types and list out the elements that make up the structure. For example, an article may have a title, author, publish date, content, images, a category and related articles. Check any technical requirements or functionality and include these as elements within your type. Be sure to include the type of data the element is referencing, for example (text) or (number).

3. Create relationships between Content Types 

The Content Model needs to show the distinct relationships between each Content Type so we know how the structure will be mapped out within the final solution. Within a project, there will be Content Types with different relationships to each other. Some Content Types will relate to many other Content Types and other Content Types will relate to just one. Within your whiteboard tool, add connectors between your content types and define the limitations for each relationship. For example, an Article can have three related Articles and three related Services but only one Category.

Kontent.ai published useful documentation on the different types of relationships, which will help when defining relationships in a Content Model.

4. Validate the Content Model

Re-visit the goals for the project and ensure the Content Model meets the requirements of the project. 

Once the Content Model has been refined and improved it should be shared with the wider team and most importantly the people who will be creating the content. The Content Model will be a good reference point for the technical team to begin building the structure within the solution environment.

Remember a good Content Model should evolve with your content, not limit it