A Content Model Is Not a Design System

Do you recall the days when having a fantastic site was sufficient? Today, people are getting answers from Siri, Google search fragments, and mobile applications, not only our websites. Companies with forward-thinking goals have adopted an holistic information strategy that aims to reach people across a range 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 information models that also connect related content, you can avoid that result.

I just had the opportunity to direct the CMS application for a Fortune 500 company. 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.

For our information to be understood by many systems, the unit needed conceptual types, which are names given based on their meaning rather than their presentation. This is crucial for an multichannel content strategy. Our aim was to allow writers to write articles and use it where necessary. 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 design systems, which we were more familiar with. An omnichannel content strategy cannot rely on WYSIWYG tools for design and layout, unlike web-focused content strategies. Our tendency to approach the content model with our familiar design-system thinking constantly led us to veer away from one of the primary purposes of a content model: delivering content to audiences on multiple marketing channels.

Two fundamental tenets govern a successful content model

We needed to explain to our designers, developers, and stakeholders that we were doing something completely different from their previous web projects, where everyone assumed that content would fit into layouts as visual building blocks. The previous approach was not only more familiar but also more intuitive—at least at first—because it made the designs feel more tangible. The team was able to understand how a content model differs from the design systems we were familiar with by discovering two principles:

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 how it will be displayed. For example, in a nonsemantic model, teams might create types like teasers, media blocks, and cards. Although these types might make it simple to present content, they don’t aid in understanding the meaning of the content, which would have opened the door to the content presented in each marketing channel. In contrast, a semantic content model uses type names like “product,”” service,” and “testimonial” to allow for each delivery channel to interpret and use the content as it sees fit.

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

Benefits of a semantic content model include:

A semantic content model also gives you a competitive advantage. By adding structured data based on Schema. A website can provide hints to Google to understand the content, display it in search snippets or knowledge panels, and use it to respond to user voice-interface queries. Potential customers could access your content without ever visiting your website.
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 piece of an article’s meaning and usefulness depend on how well it is organized. 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 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 examine how connecting related content can be used in a practical 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 flexible as possible?

Because our design-system instincts were so well-known, it appeared that we needed a “tab section” content type so that multiple tab sections could be added to a page. Each tab section would display various types of content. One tab might contain the software’s information or specifications. A list of resources might be found under 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 another system have resorted to counting tab sections and content blocks, for instance, if it had been able to identify a product’s “tab section” when referring to its specifications or resource list? This would have prevented the tabs from ever being rearranged, and it would have required adding logic 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 each tab’s specific information, such as the software product’s overview, specifications, related resources, and pricing, was intended to reveal a specific purpose. 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 it became clear that the idea of tabs wasn’t applicable to the content model. What was important was the meaning of the information that was intended to be displayed 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 decided to create content types for the software product based on the meaningful qualities 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. Team members may be persuaded to combine them and have their content model resemble their design system, so you should guard the semantic and contextual integrity of the content strategy throughout the entire implementation process. 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. structured data from org–based on your website. The benefit of search engine optimization is a compelling reason on its own, even if additional delivery channels aren’t on the horizon in the near future.
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 the compatibility between the content and the design.

By firmly defending these ideas, you’ll help your team treat content the way it deserves as the most important component of your user experience and the best way to engage with your audience.