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 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 material 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.

A content type is essential for an omnichannel information strategy, and the model needed conceptual types, which are types of types that are categorized according to their meaning rather than their presentation. Our aim was to allow writers to write articles and use it where necessary. However, as the project progressed, I realized that the entire team had to be aware of a new design in order to support willing reuse at the level that my customer needed.

Despite our best motives, we kept drawing from what we were more common with: design techniques. Unlike web-focused information strategies, an holistic information strategy doesn’t rely on WYSIWYG equipment for design and structure. Our inclination to approach the material model using our well-known design-system thinking consistently made us wander away from one of the main objectives of a willing model: delivering content to audiences across multiple marketing channels.

Two fundamental tenets govern a successful information type

We needed to explain to our designers, developers, and stakeholders that we were doing something completely different from their previous internet projects, where everyone assumed that content would fit into layouts as physical building blocks. The past approach made the designs feel more recognizable and intuitive, at first, at least initially, because it made them feel more recognizable. The team was able to know how a willing model differs from the design systems we were familiar with by discovering two principles:

Instead of design, content models may establish semantics.
And material models may connect elements that belong together.

Conceptual articles models

A conceptual content type uses form and attribute names that reflect the content’s intended purpose and not its intended display. For instance, in a nonsemantic design, groups may make varieties like teasers, press blocks, and cards. Although these types may make it simple to present information, they don’t aid in understanding the meaning of the information, which would have opened the door to the information presented in each advertising channel. In contrast, a conceptual content model employs type names like product, service, and testimony to allow for each supply route to interpret the information and use it as necessary.

A great place to start when creating a semantic content model is by reviewing the types and properties that Schema has defined. org, a community-driven resource for type definitions that are intelligible to platforms like Google search.

A semantic content model has several benefits:

A competitive advantage can also be gained by a semantic content model. by including structured, schema-based data. org’s 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 answer voice-interface user questions. Without ever visiting your website, potential visitors could easily find your content.
Beyond those practical advantages, you’ll also require an omnichannel content delivery model. 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 easily displayed on a frequently asked questions ( FAQ ) page as well as be used by a bot to answer frequently asked questions.

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 pieces of content that ought to be preserved so that multiple delivery channels can use it without having to assemble those pieces separately.

Write an essay or article about it. An article’s meaning and usefulness depends upon its parts being kept together. Without the full context of the article, would one of the headings or paragraphs have any relevance on their own? Our well-known design-system thinking on our project frequently led us to want to develop content models that would divide content into distinct chunks to fit the web-centric layout. This had a similar effect to an article that had its headline removed. Content that belonged together became challenging to manage and nearly impossible for multiple delivery channels to understand because we were cutting content into separate pieces based on layout.

To illustrate, let’s look at how connecting related content applies in a real-world scenario. The client’s design team created a challenging layout for a software product page that included numerous tabs and sections. Our instincts were to follow the content model’s. Shouldn’t we make adding any number of tabs in the future as simple and 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 a variety of content. One tab might provide the software’s overview or its specifications. Another tab might provide a list of resources.

Our tendency to divide the content model into “tab section” pieces would have resulted in an unnecessary complex model and laborious editing procedures, as well as creating content that couldn’t possibly be 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. Additionally, it would have been difficult to migrate to a new content model in response to the new page redesign if the customer had decided against displaying this content in a tab layout.

We had a breakthrough when we discovered that our customer had a specific purpose in mind for each tab: it would reveal specific information such as the software product’s overview, specifications, related resources, and pricing. Our desire to concentrate on what was visually and historically significant had obscured the purpose of the designs once implementation began. With a little digging, it didn’t take long to realize that the concept of tabs wasn’t relevant 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 chosen to display this content elsewhere in a different manner, without tabs. Based on the meaningful attributes the customer had desired to display on the web, we created content types for the software product. There were obvious semantic attributes like name and description as well as rich attributes like screenshots, software requirements, and feature lists. 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. Any delivery channel—including future ones—could understand and present this content.

Conclusion

In this omnichannel marketing project, we discovered that the best way to maintain our content model was to ensure that it was semantic ( with type and attribute names that reflected the content’s meaning ) and that it preserved content that belonged to be together ( instead of fragmenting it ). These two ideas made it easier for us to shape 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 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 having trouble making this transition, Schema can still offer some of the advantages. org–based structured data in your website. 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.
Remind the team that removing the content model from the design will allow them to update the designs more quickly because content migration costs won’t be prohibitive. They’ll be able to create new designs without compromising the compatibility between the content and the design, and they’ll be prepared for the upcoming big thing.

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