Skip to content
See Sanity in action 👀 Join us for a live product demo + Q&A →
Sanity
Get started
  • Sanity Studio - Flexible editing environment
  • Content Lake - Real-time database
  • Developer experience - Tooling you love
  • Structured content - The philosophy behind Sanity
  • Review changes - View edits & rollback instantly
  • Image pipeline - On-demand transformations
  • E-commerce - Better shopping experiences
  • Marketing sites - Control your story
  • Products & services - Innovate and automate
  • Mobile apps - Content backend for every OS
  • Aether - Unique digital shopping experience
  • Morning Brew - Omnichannel media distribution
  • InVision - Delivering exceptional customer experiences
  • DataStax - Personalization for global audience
  • React
  • Gatsby
  • Next
  • Nuxt
  • Eleventy
  • Netlify
  • Vercel
  • Algolia
  • Documentation
  • Reference
  • Guides
  • Resource library
  • Headless CMS
  • Tools & plugins
  • Project showcase
  • Schemas & snippets
  • Agency partners
  • Technology partners
  • Get support
  • Share your work
  • 5 Disadvantages Of Wordpress That Are Holding You Back
EnterprisePricing
Contact salesLog inGet started

Content Modeling Guide

  • Content Modeling: What It Is and How to Get Started
  • Laying the Groundwork for Content Modeling
  • How to Create a Content Model

Categorized in

  • Structured Content
  1. Resources
  2. Structured Content
  3. Content Modeling Guide

Published March 9th 2023

How to Create a Content Model

  • Carrie Hane

    Principal Evangelist at Sanity

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.

All about Enigma

Industry: SaaS
Product: AI video editing tool
Target audience: Professional video editors in the US
Pricing model: Subscription-based, with pricing tiers from free through enterprise

Current goals:

  • To increase brand awareness and gain more paying customers
  • To create a website that provides information about the product and highlights use cases
  • To keep the initial scope small, but prepare for the possibility of expansion

Why create a content model?

  • To ensure that early work is flexible, extensible, and scalable as the company grows and matures.

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.

Step 1: Identify potential content types

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.

Protip

Tips for identifying potential content types

  • Write down each one on a sticky note and put it on the board.
  • Stick to one concept per content type and keep the names singular.
  • Don’t worry about narrowing them down for now — just focus on getting your thoughts on a board.

Content types vs instances

Be careful to not confuse content types and instances. Content types are meant to be reusable. Instances are specific examples of the concept represented by the content type. For Enigma, a quote given by Nicola Chang is an instance of the Testimonial content type.

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.

Gotcha

One common mistake during this stage is to list something that is actually a webpage, like About or Contact Us. Anything that is describing how content is displayed on a website is not actually a content type. Remember that content models aren't about a single interface, so think beyond the website! Specific webpages do not belong in a content model for the organization, since the model is not designed for a particular interface.

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

Step 2: Consolidate and define content types

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

Step 3: Connect content types to make relationships

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.

Enigma content model showing how the content types are related.


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.

Step 4: Add attributes to your content types

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

Protip

If you’re having a hard time defining attributes for a content type, try using Schema.org for inspiration. Founded by search engines to promote structured data, it’s a comprehensive collection of schemas.

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.

Step 5: Define the data schema

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.

NOTE: Each CMS product use different terms to describe components and functionality. We will be using Sanity-specific language in this section.

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.

Who should be involved in schema definition?

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.

From content model to database schema

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
Columns in the Sanity Studio Build Workbook for defining document types.

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.

Data schema definition for Customer to be built in Sanity.

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.

Step 6: Share with stakeholders.

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.

Next steps

  • 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.
Previous
Laying the Groundwork for Content Modeling

Page content

  • Step 1: Identify potential content types
  • Step 2: Consolidate and define content types
  • Step 3: Connect content types to make relationships
  • Step 4: Add attributes to your content types
  • Step 5: Define the data schema
    • Who should be involved in schema definition?
    • From content model to database schema
  • Step 6: Share with stakeholders.
  • Next steps

Platform

Structured ContentDeveloper experienceContent LakeSanity StudioSecurity & Compliance
  • Sanity vs Contentful
  • Sanity vs Strapi
  • Sanity vs Adobe Experience Manager
  • Sanity vs Hygraph
  • Sanity vs Sitecore
  • Sanity vs Storyblok
  • Sanity vs Contentstack
  • Sanity vs Prismic
  • Sanity vs Drupal
  • Sanity vs ButterCMS

Resources

Documentation
  • React Blog
  • Gatsby Blog
  • Next.js Landing Pages
  • Progressive Web Application
  • Single Page Application
  • Svelte & Typescript App
  • Vue & Tailwind Blog
  • Developer Portfolio Templates
  • Form validation with Yup
  • Live Preview with Next.js and Sanity.io
Resource library
  • Agency partners
  • Technology partners
  • Blog Template
  • Personal Website Template
  • Developer Portfolio Templates
  • All Templates
Case Studies
  • Headless CMS
  • What is an API CMS
  • Static Sites 101
  • Headless SEO
  • Localization
  • GraphQL vs REST
  • What is a DXP?
  • Typescript 101
  • Content as a Service
  • Ecommerce SEO
  • React CMS
  • Next.JS CMS
  • CMS for Shopify
  • Content platform
  • Multilingual CMS
  • Static Site CMS
  • Gatsby CMS
  • Node CMS
  • E-commerce CMS
  • Vue CMS
  • Angular CMS
  • GraphQL CMS
  • Newspaper CMS
  • Magazine CMS
  • CMS for apps
  • Remix CMS

Company

Contact SalesEnterpriseCareersTerms of ServiceAccessibility Statement

Stay connected

  • GitHub
  • Slack
  • Twitter
  • YouTube
  • Stack Overflow
  • Blog RSS
  • Newsletter
©Sanity 2023