How to Create a Content Model

In previous chapters, we went over what a content model is, why it’s important, and the key content modeling concepts to understand before you get started. In this chapter, we’re ready to dive into the nuts and bolts by walking you through how to create a content model.

Let’s take a moment to reiterate: this is a guide for creating content models as conceptual tools based on business and content strategy before creating data models or technical specifications for database schemas.

When learning how to create a content model, we've found that walking through an example with an (imaginary) company helps make the concepts more concrete. That way, it's easier to apply them to your own unique business context. So let’s start by introducing Enigma.

Ideally, you’d approach your content model as a collaborative exercise you’ll do with other stakeholders, such as developers, designers, and the people responsible for overseeing content management and operations. But you can certainly do it on your own too.

So, let’s get started! Using Enigma as a touchstone, here’s how to create a content model.

Recall from the previous chapter that a content type is a reusable container for storing content with a common structure and purpose. It describes the consistent form that similar types of content take.

Based on what you gathered in the discovery phase, you’ll want to start by picking out the types of content that are core to your business. You’re going to need a whiteboard — either physical or virtual — for this exercise. Keep in mind that even if you’re all in the same room, using an online whiteboard makes it easier to save your work, share it, and reference it later.

As you’re thinking through content types, you might find yourself trying to decide whether something is a content type or something else. We’ll give you some guidance on how to decide in the next section.

Remember, the magic of this exercise is that you’re freeing yourself from having to think in terms of webpages. Instead, you’re thinking in terms of content. The content will then inform the webpages you need. You will eventually add pages to a website’s site map, but put them aside for now.

Here are the potential content types we came up with for Enigma:

• Article
• Blog Post
• Brand
• Case Study
• Company
• Customer
• Documentation
• Event
• Industry
• Job Description
• Market
• Pricing Plan
• Product
• Product Feature
• Team Member
• Testimonial
• Use Case

With all the potential options on the board, it’s time to determine which ones are actually content types. Sometimes multiple concepts can be combined into a single content type. Others do not belong in the content model.

Don’t get too bogged down here. Keep going until you get to a point that makes sense to you. The goal is good enough, not perfection.

To help consolidate into the content types you’ll go forward with in your model, it helps to ask the following questions out loud (in a group) or to yourself (if working alone).

1. Will this thing ever be displayed on its own? Yes, we said don’t think about a specific interface when identifying content types. In this case, it’s one way to test if a concept is a content type or part of another content type. In the Enigma example, any given Pricing Plan would only ever be part of a specific Product, so Pricing Plan would not be a separate content type in this model.
2. Does this thing have more than one attribute? If not, it may be a taxonomy term, which is helpful for defining relationships between content. For Enigma, Market is a way to identify Customers and Product availability, as well as to classify an Article, but not something that stands on its own. Set the sticky to the side for future reference and include it as an attribute in a future step.
3. How specific is the definition? Content types are most useful when they are reusable. If something is too specific to be used more than once, it probably does not need to be a content type. Enigma has only one brand, so Brand would not be a content type in this case. That would be different for a large multi-brand enterprise like Unilever. Alternatively, you could consider expanding the definition and combining two similar content types with nearly the same structure. This is what we did with the original concepts of Product, Pricing Plan, and Product Feature in Enigma's model.

It can be helpful to keep stickies that are not content types off to the side for future reference. They might be useful when creating content or designing websites or other digital properties.

For the content types that remain, define each one as you would a vocabulary term. This is important for validating what you call each content type and what it is in this context. Many words have multiple meanings. Defining what you mean is a way of documenting decisions for your future self, new team members, and others who encounter the content model down the road.

We decided to start with these seven types for Engima. Because their scope is small, we wanted to make it as simple as possible while still providing room to grow.

Article – Editorial content about the company, its products, or things it does.

Company – Information about the company

Customer – Information about businesses that buy the Company’s products

Documentation – Information to describe the use, functionality or architecture of a Product

Event – Gathering or activity hosted or attended by the Company

Product – Information about the software made by the Company

Testimonial – Quotes about what people like about the Company or Product

Now it’s time to connect the content types. Relationships describe how content types are associated, creating a shared understanding of how they are connected. Documentation is for a Product. A Testimonial is given by a Customer. These relationships extend to each instance of each content type, which opens the door to dynamic interactions when you publish content.

Here’s how we connected Enigma's content types.

On your physical board or online whiteboard, draw lines from one sticky to another to show relationships between content types. Then label those relationships. If you’ve ever had a grammar class, you might recognize these as Subject-Predicate-Object relationships. (Yes, sentence diagramming will now come in handy!)

Subject – the content type that is doing something

Predicate – what is being said about the subject

Object – the content type that receives the action

It’s helpful to use arrows to make it clear which content type is the subject and which is the object. While there is no right or wrong way to draw your lines and label them, it’s helpful to think about which content type does the work (subject) and which is affected by the action (object).

As you connect types, you might find yourself adding or subtracting from the model. Some content types will collapse into each other while others will get broken out. This is a good thing. It means you’re thinking hard about the relationships between content in your system and not taking anything for granted.

The goal is to get the model about 80% right at this point. “No model will survive first contact with real content.” (Jeff Eaton/Cleve Gibbon) So, don’t spend too much time dissecting each component of the model. As your business grows and changes, the model will continue to evolve.

At this point, your model is already a useful content strategy tool. You’ve made decisions about the type of content you will develop and maintain over time. You’ve started to gather information that will inform how you’ll configure your content management system.

When you are satisfied with your model’s content types and their relationships, the next step is to add attributes. An attribute is a characteristic or quality of a content type. Since we are not defining database schema, these are not fields. We’ll get to that eventually. For now, we are narrowing down which attributes of your content types you care about.

Any content type can have a range of attributes. But you don’t need to include them all. Instead, you and your team should decide which attributes makes the most sense for your situation. You want enough to be scalable and flexible across systems and displays, but not so many that they will never be used in your context.

For example, Enigma has Customers, which are businesses. Of all the possible attributes about a customer business, Enigma cares primarily about just a few:

Business Name
Logo
Website
Location
Point of Contact
	Name
	Email
Market
Industry
Number of employees

At this stage in the game, it’s time to break out the spreadsheet to define the attributes of each content type in your model. (We know many of you are itching to do this!) Whether you use a spreadsheet or something else, it’s important to capture the following information:

• Content types and their definitions
• Attributes of each content type that matter to your organization and audience
• Examples of certain attributes (ex: Call to action: Watch a demo, Get started for free)

It’s worth thinking through every possible attribute that belongs to your content types. The attributes are what allow you to make the most of your content as resources that can be used in many places. Don’t overthink it, though. Remember that the goal is good enough, not perfect.

Notice that so far, we haven’t talked about your website or any other specific places where you’d display content. That’s because we want to plan for content that can be used anywhere. We’ve kept the content model conceptual and at a strategic level, so it can be a flexible framework as your business evolves.

It’s time to start thinking about how the model can be applied, and how it will be used in a technical sense.

Now that you’ve outlined a structure for your content, you’ll need a database to collect, organize, and store it.

There are various types of content management systems (CMSes) available, each with their advantages and limitations. For example, the Sanity Composable Content Cloud was designed to help you to make your content modular, programmable, and reusable across channels.

We’re now ready to do the technical specifications for the CMS. Like every other step in this process, you won’t get the definition 100% right the first time, so do the best that you can.

Defining the schema requires a couple of different perspectives: someone who understands the technical implementation, and someone who understands how the team will actually be working with the content. That’s why we recommend that a developer (technical expertise) and content manager (content operations and workflow expertise) should put their heads together to figure out how to configure the CMS.

A product manager also might be involved, depending on the size of your team. Include the appropriate people for your situation.

The goal is to find the best way to set up the system based on your team’s content operations, workflow, and governance as well as the ability to maintain and extend the CMS as needs evolve.

We have a template to capture your Sanity Studio specs. If you are following this guide but using another content platform, you can modify the template to match your software’s unique properties.

In Sanity, you’ll plan out the following:

• Document types with fields specifications
• Objects
• Studio navigation

The content types from the model become the basis for Document Types. At this point, you’ll need to consider how the content will be created and managed — but not necessarily how it will be displayed. So focus on the intent and meaning of each element rather than formatting.

It may be tempting to map the content types’ attributes from the model to document type fields. Resist that temptation. The content types and attributes are a starting point, not a direct mapping exercise to document types and fields.

Once you consider how people will use the CMS to store and deliver content, you’ll find you need to get much more specific. You’ll probably have many more fields than attributes. There’s no rule for the maximum or minimum number of document types or fields. Have just enough that it’s intuitive for an author to create content and for the content to translate to a display properly.

Here’s an example of the Customer content type for Enigma. Even though Testimonial was a separate type in our content model, we decided we would only have testimonials from customers, and that each customer could only have one testimonial. So we combined the testimonial fields with the information about the Customer and called it a quote.

Keep in mind that you can reference other document types. This is why we created relationships in the content model. Those relationships might become references. When you use a reference, you’re telling the underlying database, “Connect this instance of the thing I’m creating to that instance of another type of thing.” With that connection, all the fields from both content types are available to use in any display.

Let’s say Enigma is putting on an event for videographers to meet up and share tips. The document type here is Event. The Event has Speakers, which are stored in a separate document type. When specifying that the event features Annie Leibovitz as the keynote speaker, you only need to select Annie Leibovitz from a list of possible Speakers in the Keynote Speaker field of the Event.

When it’s time to create the event detail page, you can use any of the fields from both content types. No need to enter the speaker’s name, headshot, and Instagram ID again on the event. Likewise, the kiosk at the venue where the event is held can flash the event name, logo, date, and “featured speaker” Annie Leibovitz’s name and photo because of this relationship. Content really can go everywhere now!

Oh no! Someone spelled Annie’s last name wrong! No problem: go in to her Speaker document, add the t to Leibovitz and voila! It’s fixed everywhere in a matter of seconds.

Creating a content model with a group will create alignment across teams and connect the various silos in your organization. Once you’re done, make sure to socialize your model with other people who might benefit from it. Give them the chance to share their feedback and ask questions. A content model is a living document that will evolve over time.

• Try it on your own! Don’t be afraid to start slowly with part of a model or a rough sketch. Content modeling is art and science — and there is no right answer.
• Use the Studio worksheet template for documentation and discussion with your team.
• Join the Sanity community and ask questions in the #content-modeling channel.