A Content Model Is Not a Design System

Do you recall the days when having a fantastic site was sufficient? Nowadays, people are getting answers from Siri, Google seek fragments, and mobile applications, not only our websites. Companies with forward-thinking goals have adopted an holistic information plan whose goal is to reach people across a variety of digital stations and platforms.

However, how can a content management system ( CMS ) be set up to reach your audience both now and in the future? I learned the hard way that creating a content model—a concept of information types, attributes, and relationships that let people and systems understand content—with my more comfortable design-system wondering would collapse my patient’s holistic information strategy. By developing conceptual material models that also connect related content, you can avoid that result.

A Fortune 500 company recently tapped me to guide the CMS application. The customer was excited by the benefits of an holistic information plan, including material modify, multichannel marketing, and robot delivery—designing content to be comprehensible to bots, Google knowledge panels, snippets, and voice user interfaces.

A content type is essential to an omnichannel content strategy, and it required conceptual types to be given names that don’t depend on how the content is presented. Our goal was to allow writers to create original content that could be used wherever they felt was most useful. But as the job proceeded, I realized that supporting material utilize at the range that my client needed required the whole group to identify a new pattern.

Despite our best efforts, we remained influenced by what we were more common with: design techniques. An holistic content strategy doesn’t rely on WYSIWYG equipment for design and layout, unlike web-focused willing strategies. Our tendency to approach the material model with our common design-system thinking frequently led us to veer away from one of the main purposes of a material model: delivering content to audiences on various marketing channels.

Two fundamental tenets are necessary for a successful content model

We needed to explain to our designers, developers, and stakeholders that we were undertaking a very different task from their earlier web projects, where it was common for everyone to view content as visual building blocks that fit into layouts. The previous approach was not only more familiar but also more intuitive—at least at first—because it made the designs feel more tangible. We learned two guiding principles that helped the team understand how a content model and the design processes we were familiar with were:

Instead of layout, content models must define semantics.
And content models should connect content that belongs together.

Semantic content models

A semantic content model uses type and attribute names that reflect the content’s intended purpose and not its intended display. For example, in a nonsemantic model, teams might create types like teasers, media blocks, and cards. These types may simplify the presentation of content, but they do not aid in understanding the meaning of the content, which would have opened the door to the content presented in each marketing channel. To allow each delivery channel to comprehend the content and use it as it sees fit, a semantic content model uses type names like product, service, and testimonial.

When you’re creating a semantic content model, a great place to start is to look over the types and properties defined by Schema. a curated resource for type definitions that are understandable on platforms like Google search, type definitions .org

A semantic content model has a number of advantages:

A semantic content model also gives you an advantage in the market. By adding structured data based on Schema. Using its types and properties, a website can provide hints to help Google understand the content, display it in search snippets or knowledge panels, and use it to respond to voice-interface user questions. Without ever visiting your website, potential visitors could easily find your content.
Beyond those practical benefits, you’ll also need a semantic content model if you want to deliver omnichannel content. Delivery channels must be able to comprehend the same content in order to use it across multiple marketing channels. For instance, if your content model provided a list of questions and answers, it could be used as a voice interface or by a bot to answer frequently asked questions ( FAQ ) pages.

For example, using a semantic content model for articles, events, people, and locations lets A List Apart provide cleanly structured data for search engines so that users can read the content on the website, in Google knowledge panels, and even with hypothetical voice interfaces in the future.

Content models that connect

Instead of slicing up related content across disparate content components, I’ve come to the realization that the best models are those that are semantic and also connect related content components ( such as a FAQ item’s question and answer pair ). A good content model connects content that should remain together so that multiple delivery channels can use it without needing to first put those pieces back together.

Write an essay or article about it. The meaning and usefulness of an article depend on how well its components are kept together. Would one of the headings or paragraphs be meaningful on their own without the context of the full article? Our well-versed in designing systems frequently led us to want to develop content models that would break content into smaller pieces to fit the web-centric layout. This had a similar effect to an article that had its headline removed. Because we were slicing content into standalone pieces based on layout, content that belonged together became difficult to manage and nearly impossible for multiple delivery channels to understand.

Let’s take a look at how connecting related content works in a real-world setting to illustrate. A complex layout for a software product page that included multiple tabs and sections was presented by the client’s design team. Our instincts were to follow suit with the content model. Shouldn’t we make adding any number of tabs in the future as simple and as flexible as possible?

We felt like we needed a content type called “tab section” because our design-system instincts were so well-known, so that multiple tab sections could be added to a page. Each tab section would display various types of content. The software’s overview or specifications might be available in one tab. A list of resources might be provided by another tab.

Our inclination to break down the content model into “tab section” pieces would have led to an unnecessarily complex model and a cumbersome editing experience, and it would have also created content that couldn’t have been understood by additional delivery channels. How would a different system have been able to determine which “tab section” referred to a product’s specifications or resource list, for instance? Would that system have had to have used tab sections and content blocks to calculate these terms? This would have prevented the tabs from ever being rearranged, and logic would have had to be added to each other delivery channel to interpret the layout of the design system. Furthermore, if the customer were to have no longer wanted to display this content in a tab layout, it would have been tedious to migrate to a new content model to reflect the new page redesign.

Our customer had a breakthrough when we realized that for each tab, their customer had a specific purpose in mind: it would reveal specific information like the software product’s overview, specifications, related resources, and pricing. Once implementation began, our inclination to focus on what’s visual and familiar had obscured the intent of the designs. It wasn’t long after a little digging that the idea of tabs wasn’t applicable to the content model. What was important was the meaning of the information that they intended to display in the tabs.

In fact, the customer could have decided to display this content in a different way—without tabs—somewhere else. In response to this realization, we created content types for the software product based on the meaningful attributes the client wanted to display on the web. There were rich attributes like screenshots, software requirements, and feature lists as well as obvious semantic attributes like name and description. The software’s product information stayed together because it wasn’t sliced across separate components like “tab sections” that were derived from the content’s presentation. This content could be understood and presented by any delivery channel, including those that come up in the future.

Conclusion

In this omnichannel marketing project, we discovered that the best way to keep our content model on track was to ensure that it was semantic ( with type and attribute names that reflected the meaning of the content ) and that it kept content together that belonged together ( instead of fragmenting it ). These two ideas made it easier for us to decide what to do with the content model based on the design. Remember: If you’re developing a content model to support an omnichannel content strategy, or even if you just want to make sure that Google and other interfaces understand your content, keep in mind:

A design system isn’t a content model. You should maintain the semantic value and contextual structure of the content strategy throughout the entire implementation process because team members might be drawn to conflate them and force your content model to resemble your design system. This will enable each delivery channel to consume the content without the need for a magic decoder ring.
If your team is struggling to make this transition, you can still reap some of the benefits by using Schema. Your website uses structured data from org. The benefit of search engine optimization is a compelling argument on its own, even if additional delivery channels aren’t on the horizon at this time.
Additionally, remind the team that decoupling the content model from the design will let them update the designs more easily because they won’t be held back by the cost of content migrations. They will be prepared for the upcoming big thing, and they will be able to create new designs without compromising compatibility between the design and the content.

You’ll help your team understand these principles by firmly defending them in their efforts to give content the attention it deserves as both your most valuable resource and your most effective way to engage with your audience.