Full process example
#Overview
In this document, we will walk through the full process of building a content model using a simple & practical example. We'll use the example of a bookshop website again, which we used for some of the examples we shared in the previous documents.
This step-by-step example shows you how to approach content modeling, starting with desk research and interviews, working with cross-functional teams, and finally building a content a schema in Hygraph for a basic website that sells books. Following this method will help you make sure that your Hygraph project is structured properly, and is flexible & scalable.
#1. Desk research & interviews
The content modeling process starts with research. For our example, imagine that you work for a chain of bookshops that asked you to build a content model for their website. You'll begin with desk research to understand the domain. That is, how bookshops typically structure their information, from book details to genres, authors, and reviews.
You'll need to gather information about how bookshop websites display their content and what users expect.
Once you have a basic understanding, it's time to interview key stakeholders:
- Content creators who will use the CMS to enter book details, manage inventory, and create content.
- Sales team to understand how customers interact with the site and what information facilitates sales.
- Developers to learn about their preferred tech stack, and understand how they need content to be structured for scalability and good performance.
- Marketing team to get information about customer engagement and promotional content.
After your research and interviews, you'll have a list of terms that will be the foundation of your content model. For the sake of this example, we created this list for you:
- Books
- Authors
- Genres
- Reviews
- Price
- ISBN
- Availability
- Promotions
#Relationships between terms
You'll need to think about how these concepts relate to each other. We've thought of some examples for you:
- Each Book is written by one or more Authors.
- Each Book belongs to one or more Genres.
- Each Book may have multiple Reviews.
- Each Book has one ISBN.
- Each Genre may have several Books and Authors.
- Each Book has one Price.
After identifying these concepts and their relationships, the next step is to decide which ones will serve as object domains and which will act as attributes. Let's move forward to the next step, where we will build the domain model.
#2. Building the Domain Model
Next, bring in your cross-functional team to build the domain model. This model will represent the entire business (everything from managing inventory to customer engagement). It's fundamental to include members from different departments to make sure that all parts of the business are taken into consideration.
For example, in our bookshop example, the domain model would cover:
- Inventory: Books, Authors, Genres.
- Customer Reviews: User feedback on books.
- Sales and Promotions: Book prices, discounts.
- User Engagement: Popular books, new arrivals.
- Business Management: Stock availability, order processing.
- Store Locations: Physical shop locations, contact details, operating hours.
- Employee Management: Staff details, roles, scheduling.
- Suppliers: Supplier contact information, orders, contracts.
Teamwork should result in a high-level domain model for the bookshop that contains a list of object domains and considers how they are related.
Here is a list of possible object domains and some attributes related to them:
Domain objects | Attributes |
---|---|
Books | Title, ISBN, price, availability, summary, cover image. |
Authors | Name, biography, photo. |
Genres | Name, description, authors, books. |
Reviews | User name, rating, review text. |
Promotions | Discount name, description, amount, active period. |
Store Locations | Shop name, address, contact details, operating hours. |
Employee Management | Employee name, role, shift schedule, contact information. |
Suppliers | Supplier name, contact information, order history, contracts. |
Here is a list of possible relationships:
Domain objects | Relation |
---|---|
Books and Authors | A book is written by one or more authors. An author can write multiple books. |
Books and Genres | A book belongs to one or more genres. A genre can have multiple books associated with it. |
Books and Reviews | A book can have multiple reviews from different users. A user can review multiple books. |
Reviews and Authors | An author can have multiple reviews from different users. A user can review multiple authors. |
Books and Promotions | A book can be associated with one or more active promotions (such as discounts or pre-ordering). A promotion can apply to multiple books. |
Reviews and Users | A review is submitted by a single user. A user can submit multiple reviews. |
Books and Promotions | A sale or discount can be applied to available books. |
Books and Suppliers | A supplier provides one or more books. A book may be sourced from multiple suppliers. |
Store Locations and Books | A store location stocks multiple books. A book may be available in multiple store locations. |
Suppliers and Store Locations | A supplier provides stock to one or more store locations. A store location receives stock from multiple suppliers. |
Employee Management and Books | Employees may be responsible for specific books (for instance: curating, doing inventory or stocking). |
Promotions and Store Locations | A promotion may be applied to specific store locations. A store location may have multiple promotions. |
The goal of the domain model is to provide a full picture of how the business operates. However, when creating your schema for the website, you'll only include object domains directly related to the content that users will interact with, such as Books, Authors, Genres, and Promotions.
While the domain model shown above includes all aspects of the business, not every object domain will be necessary for the content model (schema) when building an online bookshop website.
Here's an example of how you can select which parts to leave out:
- Store locations: This applies to the physical stores but may not be needed for a simple online bookshop content model.
- Employee management: This is essential for business operations, but not relevant to customer-facing content.
- Suppliers: This is important for business management, but not part of the content that users interact with online.
#3. Build the schema
Now that we have a domain model, we need to focus on the part of it that's relevant to our website's content. In this case, we'll create a content model for displaying books and their related information on a product page.
In Hygraph, the content model is called the schema, the content types are called models, and the attributes are called fields. We'll use Hygraph vocabulary from now on.
Here is a high level Schema that we created using the Domain Model from the previous section:
- Book (Content Type/Model).
- Fields: Title, ISBN, Price, Summary, Availability, Book cover, Genres (Reference), Author (Reference), Reviews (Reference), Promotion (Modular component field).
- Author (Content Type/Model).
- Fields: Name, Biography, Photo, Books (Reference), Genres (Reference), Reviews (Reference).
- Genre (Content Type/Model).
- Fields: Name, Description.
In Hygraph, you define your project schema by creating models and adding fields to them. We've already defined our models based on the domain model, but only briefly listed the specific fields we want to add to them.
Let's look closely into each of these fields in Hygraph.
#Book Model
This is the primary content type on our bookshop website.
Field | Description |
---|---|
Title | A Single line text field for the book title. |
ISBN | A Single line text for each book as a unique identifier. |
Price | A Float field to store the book's price. |
Summary | A Rich text field for the book description. |
Availability | A Boolean field indicating if the book is in stock. |
Book cover | An Asset picker field to upload the book cover image. |
Genres | A two-way Reference field linking to the Genre model . |
Author | A two-way Reference field linking to the Author model. |
Promotion | A Basic component field that allows adding a promotion component previously created in the project. |
#Promotion component
This component could contain the following fields:
Field | Description |
---|---|
Name | A Single line text field for promotion name. |
Discount | An Enumeration field that allows selecting a discount from a list. |
Description | A Rich text field for the promotion description. |
Image | An Asset picker field to include an image related with the promotion. |
A component is a predefined group of fields that can be reused across different models.
Components like this make your content model more flexible and modular, allowing editors to reuse promotional information without duplicating content.
#Author Model
This model stores information about the book's author.
Field | Description |
---|---|
Name | A Single line text field for the author's name. |
Biography | A Rich text field for the author's bio. |
Photo | An Asset picker field to upload the author's image. |
Books | A two-way Reference field linking to the Books model. |
Genres | A two-wayReference field linking to the Genre model. |
#Genre Model
This model categorizes books based on their genres.
Field | Description |
---|---|
Name | A Single line text field for the genre name (for instance: Fiction, Non-Fiction). |
Description | A Rich text field to provide more information about the genre. |
Authors | Reverse field of the Genre reference in the Author model. |
Books | Reverse field of the Genre reference in the Book model. |
#Next steps
By now, you've created a schema in Hygraph that reflects the models and fields that we outlined above. This structured, scalable approach can now be used to expand your bookshop website or any future projects where content modeling is key.
This schema allows editors to easily create content while developers can query it efficiently via the API. It also guarantees that users will have a smooth experience where elements are connected in a cohesive way that reflects the real world.
When working on future content modeling projects, apply the gradual bottom-up approach we showed you here. Building complex systems by focusing on individual components first ensures each part is well integrated into the whole. Involving a cross-functional team guarantees that all voices are heard and all perspectives are taken into consideration.
In the future, as your business evolves and grows, it is a good idea to regularly test and iterate on your content model to make sure it still aligns with your business needs. This way, you can make adjustments before misalignment becomes an issue.
Remember that the model we built is not meant to be static and rigid, instead look at it as something that will necessarily change overtime.
#Resources
Here's a list of additional resources that you can look into:
Document | Description |
---|---|
Getting started | Our getting started tutorial project takes you from project planning to schema creation and frontend implementation. |
Hygraph recipes | Our recipes help you discover what elements you can create in your Hygraph project using different configurations. |
Implementation guides | Our implementation guides are perfect for devs who need a little help connecting their Hygraph project to a frontend. |
Integration guides | Our list of integrated apps is constantly growing. Check them out to find out how they can enhance your project. |