Why UX Designers Should Know Content Modeling
Content modeling makes content reusable and enhances usability. It simplifies the work for editors, enables new features, and improves collaboration between designers and developers, leading to more effective and intuitive digital solutions.
Content
The benefits of a good content model
What is Content Modeling?
Different content types in a model
Who should model?
Get Started
The Benefits of a Good Content Model
- A well-designed content model provides more user-friendly publishing solutions for content editors, making it easier for them to produce higher-quality content for end users.
- The value of content increases by converting it into structured data that is accessible and reusable across multiple relationships, contexts, and platforms.
- Properly structured data enables new features and services for system users, creating unique strategic advantages by establishing new relationships between existing content types.
What is Content Modeling?
Our Definition of Content
When we talk about content in a digital system, such as an online store, we primarily think of elements like images, descriptions, prices, and other general information—anything published on the website to help you understand the products and make purchasing decisions. But content encompasses more than just these visible elements.
Content also includes more hidden information, such as product IDs, exact stock levels, your browser’s location, and the last time you logged into the site. It also comprises all the visual elements that make up the user interface of the online store, from the main menu and breadcrumb trails to image carousels, buttons, labels, informational text, and all other elements you see and interact with.
This content is carefully selected by someone, and in many cases, it can be controlled and edited by editors on the website—or even by end users themselves, as seen on social media platforms like Instagram or Facebook.
To put it in more technical terms: content in a digital system consists of all data points and visual elements that make up both the front-end (user interface) and the back-end (administration interface) of the system.
What is Modeling?
A model is a realistic representation of something. "Modeling" is the process of planning and designing this representation. In our context, content modeling involves creating a representation of how content is structured within the system—a representation that ideally mirrors the real world.
Credible representations based on reality are a fundamental principle in content modeling. The goal of content modeling is to organize content in a way that makes sense to most people and to clarify the relationships between different types of content. Therefore, it is crucial that modeling is based on something we all understand well, like the actual world around us, rather than focusing solely on database structures or other technical logic of the tool in which the content will be implemented (see Difference Between Content Model and Data Model).
In other words, modeling is the design process where the content in a digital system (information and visual elements) is structured and organized so that it is meaningful for all users of the system, both end users and administrators.
Difference between content model and data model
While the content model should be based on the real world to be comprehensible to most people, a data model is often optimized for an efficient database structure that maintains data integrity and technical requirements. The key is to create models that do not hinder each other but reflect each other as much as possible.
Furthermore, a data model will generally have more attributes or properties than a content model—the reverse is not possible. For example, the content model of an image typically includes the following attributes:
The corresponding data model might look like this:
As we can see, the content type "Image" has more attributes in the data model than in the content model. In this example, one might choose to incorporate additional attributes from the data model into the content model, such as creation date or file size, if it improves and/or makes the system easier to use.
Different Content Types in a Model
A content model typically consists of content types, their attributes/properties, and the relationships between them. We usually work with three content types: objects, page types (documents), and components. There is often overlap between these types, and it’s not always clear which type best fits the content you are working with.
Technically, there is no difference between the various content types (often referred to as schemas by developers), as they are built from the same foundational elements. Distinguishing between these types is often necessary because the platform on which the system is being developed (e.g., Sanity) requires the developer to select a specific content type when it is created. Therefore, the type should be clearly defined in the model.
Page types
This is a content type that reflects the content of a specific page on a website or application. The simplest way to build the content model for a page type is to sketch out how you want the page to look and then name all the elements on the page. Here is an example of what the content model for an article might look like.
Objects
In the example above, four other content types are referenced: Images, Authors, Categories, and Tags. In this case, none of these four content types will be presented as individual pages. Therefore, these content types can be referred to as objects.
Objects are content types that contain information used throughout the system, such as properties of other objects and page types, without having a defined way for this information to be displayed. A general rule of thumb is that if a property of a content type is used multiple times in different contexts, it can be separated out as a distinct object. This avoids having to repeat the same information multiple times within the system.
An object type is almost always used as a reference to other content types and is generally meaningless on its own without being connected to something else. For example, a Tag is a content type used to categorize and group articles, images, products, etc. A tag, in isolation, might not have much meaning, but when associated with a product or article, it makes sense. Consider the tag “sustainability.” This tag could be used to group an image of a recycling plant, a pair of pants made from organic cotton, and an article about circular economy. By using the same object every time something is tagged with “sustainability,” you create opportunities to filter and present content in engaging and relevant ways for users.
Objects can be simple, with only one or two attributes, such as the Tag object (with just a title). Other objects can be more comprehensive, such as the Author:
Components
The term "components" is used to refer to different things in various contexts. In our context, I use "components" to describe visual elements that serve as building blocks for the graphical interface in the digital solution.
Incorporating visual components into a content model is not very common, but it proves to be extremely useful. The reason for this is twofold: First, it simplifies the implementation of the graphical interface (front end) because the model helps explain how the visual component functions, its variants, and where the information is sourced to populate the component with content.
Second, modeling contributes to creating a logical interface and improving usability for editors in the publishing solution.
A typical component might be a promotional banner used in various places on a website. The content model for such a banner might look like this:
Who Should Model?
Standard workflow in designing and developing new digital solutions often occurs in the following way:
The designer acquires insights about the client and their customers (end users) and works with the client to define what tasks the solution will help the users with.
Based on this insight, design of the digital solution starts which usually results in a series of screenshots showing what the digital solution should look like. In many cases, the screenshots are assembled into a clickable prototype that both end users and the client can test before the designer transfers the project to the developers for implementation.
In parallel with the design work, the developers, in turn, have mapped out technical specifications, the need for integrations with third-party systems, etc. They have, as a rule, defined the technical platform on which the system will be built and started work on setting up the framework for the selected platform and any integrations/APIs.
Once developers receive ready-made design sketches work starts on decoding the design and components, understanding where data presented should be sourced from, mapping out any variants a component may have and finding a good way to give content editors and administrators editing control over content and component variants.
This is no easy job. Especially if the designer is not available for questions and sparring. Often it can end in a guessing game where the developer sees himself having to assume what is the designer's intention, and in very many cases the design has to be slightly modified to make it fit with the platform's computer models and any limitations.
Designer may be responsible for the content model
To avoid the guessing game where the developer spends time guessing what the designer intends, I can highly recommend that the designer contribute greatly on the content modeling. This has three obvious advantages:
The first reason why the designer should work with content modeling is that it gives the designer a better understanding of the complexities that many developers face every day. We designers tend to design components and logic that are not always efficient and/or appropriate from a developer's standpoint. By working with the content modeling, we get a look into the other side, thus increasing our ability to pay attention to how it all should fit together.
Secondly, it simplifies the knowledge transfer from designer and developer. When the designer describes a graphical interface using content models, it becomes easier to communicate functionality that does not lie implicitly in the graphical interface. There will simply be less information “lost in translation” and much less guessing for the developer
The third point is about user-friendly publishing tools. While many developers master the near-impossible balance of both writing efficient code that speaks well to computers and at the same time developing management tools that are easy to use for non-technical editors, designing management tools is at the heart of what UX designers should be responsible for. Content modeling is arguably the exercise that has the greatest impact on the logic and usability of system administration, and the responsibility can therefore usefully lie with the designer role.
Developers are responsible for data modeling
One of the reasons why content modeling has traditionally not been a designer's responsibility may be related to the fact that the developer has to do data modeling in all cases. The computer models must meet the technical requirements of the technological solutions used and therefore do not have human needs as the first priority. Of course, that does not mean that computer models are not understandable to humans, but that the most important task of the computer model is to attend to the business logic, not the end user.
For the designer working on the content models, it is important to communicate well with the developer team so that computer models and content models follow more or less the same logic and that one model does not put sticks in the wheels of the other.
Users know best
Ultimately, it is neither the designers nor the developers who will be using the system we are working on. The users of the systems are always on the fence about what logic must underlie, what information must be visible or hidden, and what relationships must be taken into account. I try to involve the client and editors along the way in the content modeling to gain an understanding of how they think about the content, terminology, logic and what tasks they need to solve.
The collaboration between designer, developer and editor helps shape robust and scalable content models. Models that provide flexible and easy-to-use publishing solutions, structure data efficiently and open the possibility of using data in new, innovative ways.
Get Started
9 questions before you start
- What data do we have from before and where does it come from?
- What kind of content do we want to create, collect or procure?
- What kind of content and functionality do end users need?
- How do the editors and content producers work?
- What mental models do content producers and end users have?
- How should the content be edited?
- Which structure/model provides the best flexibility? What are attributes and what are references?
- Are there existing content models we have to deal with?
- Does the technology we are going to use provide any guides for the design of the model?
Start with the most important content type
There are many ways you can start your content modeling. Sometimes it's helpful to start by creating boxes with all the content types you've found in your insightful work. These boxes you can then categorize, move around and draw relationships in between. Once this is in place, you can then assign properties to each content type.
My preferred way of modeling content is not to map everything before adding the properties and relationships, but rather start with the main content type of the system. In large complex systems, it may not always be so easy to say what is most important, but usually a type of content stands out that feels right. It doesn't really matter what content you start with, as long as you get started.
Let's take an example. You are going to create a digital “what's happening” calendar for the municipality where you live. The most important content of such a calendar is probably the activities or events in the calendar. Let's call the content type “Events”. Furthermore, based on our knowledge of the activities that are going to enter the calendar, we can define some common features for all activities. They have an Organizer, a Type of Event, Time for the start of the activity and a Venue where the activity will be held. Furthermore, the event needs a Description, an Image and the option of Link to ticket sales.
The Event content model currently looks like this:
And that's now the fun begins. Now, when we look at the various attributes, we see that several of them can usefully be their own objects. Organizer, Type of event, and Venue are attributes that can be applied to multiple activities. So let's start with Organizer. We know that the organizers should have a separate presentation page on the digital solution where all their activities are gathered. Therefore, some additional information is needed:
The next content type is Venue. Most activities take place in places that are rented out to different activities and it is therefore useful to have a separate content type for these so that the information is consistent and that administrators do not have to re-enter all the information each time.
Finally, we want the Type of Event to be structured, meaning that administrators do not enter the type in free text every time, thus depriving the system of the ability to filter and categorize on Type. There are two ways to go about it. We can create a separate content type for event type or we can leave the evnet type only a unique property in the Event content type. The last option removes the possibility that other content types can use the categorization. In this case, it's okay to let Type of Event be a unique property rather than a reference to a separate object.
Activity with referring content types would then look like this:
Once you've worked a bit on the modeling, you can effectively proceed to sketching simple wireframes of the graphical interface. By jumping back and forth between working methods, it becomes easier to progress in the work. Personally, I tend to change method when I'm no longer able to work in flow.
Eventually, there will be a need to gain more insight in order to move forward. Then it is important not to work based on your own assumptions, but actually draw in the necessary expertise, whether from the client, end user or developer. And in some cases, all at once. Don't be afraid to show off unfinished work. That's when it's easiest to make changes and improve the solution.
Good luck with your modeling!
Do you have comments, questions, or need help getting started? Contact CEO and advisor Morten M. Wikstrom
What can we help you with?
