#Deconstructing subjects

Effective content modeling requires understanding your business goals. You should begin by researching your business and breaking down subject areas before planning your content structure.

References

Consider the key concepts in your subject domain and how they connect. Your content strategy should support these relationships. To discover this information, your research can start online but should ideally include interviews with SMEs and users.

The result of this process should include a list of terms and definitions that you will use when modeling your content. These concepts will help you build a schema that clearly suits your business and can be easily understood by your users.

#Involve users & stakeholders

Content modeling requires collaboration across teams. Research will help you get started with enough information to prepare questions for the interviews you'll conduct, and input from different roles ensures the model is both scalable and aligned with user and business goals.

Ideally, you will start with research and only then move on to modeling. Let's think about who should be involved, why, and how you can involve them.

#Who

You will research your subject domain with the goal of deconstructing it to find out its key concepts and relationships. While you can start your exploration by doing desk research, it is important to "bring in the experts". SMEs - or subject matter experts - could be researchers, individual contributors from within your company, and even external experts when possible & necessary.

• Researchers: If your company employs UX researchers or BI professionals, it's a great idea to involve them! UX researchers will have a lot of information about user behavior and needs, and BI professionals can give you a lot of information about business performance and trends. They make excellent SMEs, because the information they provide can help ensure that the content model aligns with both user experience and business goals.
• Individual contributors: Your company has people who know the business well, use the CMS daily, or both! They make great SMEs because they can provide different perspectives of the business landscape and the work that needs to be done. Your developers will have a preferred tech stack, your editors can offer unique insights about the problems they deal with every day with content creation - they can surely share what would be nice-to-have! - your sales people can tell you what the customers like the most about your product, and your customer support people can share the pain points users repeatedly have when using the product.
• External experts: Depending on what your subject matter is, you might want to bring external experts in to share some of their knowledge with you.

#Why

You want to approach content modeling as a cross-functional team because their different perspectives perspectives and experience will contribute to a comprehensive and scalable model.

Collaborating with different roles, such as UX researchers, BI professionals, and developers, helps ensure the content model meets user needs, aligns with business goals, and addresses technical requirements.

Collaborating this way reduces silos, improves decision-making, and contemplates the experience of those who will use the content model for their daily work later on.

#How

Start gathering information by interviewing SMEs, including internal contributors, researchers, or external experts like we mentioned above. The information that they share with you will be very useful to start shaping the content model.

Interviewing an expert requires preparation. You need to think about possible questions to ask, along with a way to save the information you're gathering. Recording interviews is a great way to do this. Just remember to get the interviewee's consent.

If you already have some concepts in mind for your content model, you could do a card sorting exercise where you ask your interviewee to organize the cards by categories while thinking aloud (explaining the reason behind each decision). Since you're still gathering information at this point, when you prepare the cards, leave some blank ones and bring them to the interview along with a pen, so the interviewees can create new cards to add and sort. This is an effective and engaging UX technique.

You will later use the information you gathered to create a list of terms, their definitions, and how they relate to each other. You will later use these terms to start building your content model.

Think carefully about these concepts, and think about which ones are object domains and which ones are attributes. If a concept can be answered with a specific value, it's likely an attribute rather than an object. An attribute is a characteristic or quality of an object. For example, name is an attribute of the author concept.

#Domain model creation

Now that you have your list of objects and some information about how they relate to one another, it's time to bring the cross-functional team together and start building the domain model. The resulting domain model needs to be a common vision of your subject domain.

The domain model represents the overall structure of your business, including the key concepts, entities, and their relationships. It focuses on understanding how the different elements that make up your business — customers, products, orders, etc. — interact within the system at a high level.

A great way to work on this together is to have meetings where you organize and relate the objects using sticky notes. Since you've done your research before this, you will have a list of objects and an idea of how they relate to one another. This will help you set up a first draft sketch that you can present to the extended team later to kickstart the discussion.

The team will build on the research, breaking down the business into key objects and defining meaningful relationships. This will ensure that the content model aligns with both business objectives and user needs.

#Schema creation

Now that you studied your business and created a domain model that shows the real-world concepts behind it and the logic of how they relate to each other, it is time to move on to the final step and create your schema. Your schema will be a portion of that total represented by the domain model, the part that you want to bring into the CMS and then publish.

Hygraph project schema

You will look at your domain model and select which objects and relations represent the content that you will be creating and, therefore, make sense to include in your project. When building a schema, use the object domains that you identified and organized when creating the domain model. These will become content types (models) in Hygraph, helping organize content and define relationships.

Again, this is not a task you will do alone. You should collaboratively choose which objects and relations from the domain model to bring into the schema.

After selecting your content types (”models” in Hygraph), define the attributes (specific values or characteristics that describe each object). In this context, think of your attributes as the fields you add to the models during schema creation.

So, for instance, if you have an Author model, then name, bio, and picture could be fields inside it. In the same way, if you have a Book model, then name and summary could be fields in it. In Hygraph, models relate to each other through reference fields. So, in this example, you could establish a relation between the Author and Book models containing a reverse field, meaning you can browse books by author and vice versa.

The result of this process will be a schema containing a set of models linked by references. Each model will contain a set of fields representing its attributes.

#Content templates & dynamic page composition

Content templates & dynamic page composition

Let's think of the models as templates that we created using the structured content that we carefully organized and categorized into a domain model that later became our project schema. During the planning process, you thought about the models and the attributes - or fields - in them. So, by the time you actually build them, you should have a pretty good idea of what these “templates” should contain.

Now is the perfect time to think about your headless CMS and the features it offers. For instance, Hygraph allows creating components, which are sets of fields that you can reuse in different models without having to duplicate a certain set of fields each time. Component fields can be basic or modular, with basic component fields allowing you to add a single or multiple instances of the same component, and modular components allowing you to add one or more instances of a component to a component field, which editors can then select from a dropdown.

So, with Hygraph, you could easily create a dynamic model that can be populated with different data depending on what the editor needs to do.

Following the example of the bookstore that we have been using in this document, you could create two banner components for your website, one that shows special offers and deals, and another that contains a slider that shows the latest arrivals. You could then add this as a modular component field to your Book model, meaning that when editors create a book content entry, they will have the possibility to add a banner of their choice - from the available options that you configured - or maybe no banner at all. Likewise, if you add an optional reference field to add related books, some book entries may content banners and related books, while other ones don't. You have one content model for books, but you can use it to create book entries that look different.

#Taxonomy

You can create a classification system to organize and categorize information in your project. This is what you call taxonomy. You'll create a structured hierarchy that will help you establish relationships between your models and even your content.

Good taxonomy makes information easy to find, manage and reuse. It also ensures that your content will be consistently classified, which improves searchability and therefore contributes to a better user experience.

Following the bookstore example that we used in the previous section, you could add categories for book genres. To achieve this in Hygraph, you could create a model called Genre containing a single line text field for the genre name and a rich text field for its description. Then, you'd create a content entry per genre:

• Fiction
• Non-Fiction
• Mystery
• Science Fiction
• Fantasy
• Biography
• Self-Help
• Children's Books
• Historical

Now that you have your categories, it's time to relate them to the Book model that we discussed in the previous section. You'd go over to the Book model in the schema builder and add a two-way reference field that can reference only the Genre model, and that can add multiple entries from both models as relations. The result is that when your editors create a content entry for a book, they will be able to select one or more of those content entries that you create for each book genre. Additionally, when navigating the website for this bookstore, customers would be able to search for a book they like and, in addition to looking into more books from that author like we shows you in the previous section of this document they would be able to navigate the categories themselves, finding - for instance - all the science fiction books in stock.

#Terminology

If you read books about content modeling or do online research, you will notice some terminology differences with Hygraph projects.

Here's a table that maps common content modeling terminology to their Hygraph terminology counterparts: