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. Forward-thinking companies have adopted an holistic information strategy whose goal is to reach audiences across a variety of digital channels and platforms.

How can a content management system ( CMS ) be set up to reach your current and future audience? 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 willing versions that are conceptual and that also connect related information, 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 objective 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 style in order to support material reuse on the level that my customer needed.

Despite our best purposes, we kept drawing from what we were more common with: design techniques. Unlike web-focused material 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 material model: delivering content to audiences across multiple marketing channels.

Two fundamental tenets must be followed in order to create a successful information type

We needed to explain to our designers, developers, and stakeholders that we were undertaking a very unique task from their earlier web projects, where it was common for everyone to view content as physical building blocks that fit into layouts. The past view 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 information that belongs together should be linked to material models.

Lexical material 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 produce varieties like teasers, press blocks, and cards. These types may make it simple to present information, 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 distribution channel to comprehend the information and use it as it sees fit, a conceptual content type uses kind names like product, service, and testimonial.

A great place to start when creating a conceptual content concept is by reviewing the types and qualities that Schema has defined. com, a community-driven tool for type meanings that are comprehensible to platforms like Google search.

A semantic information model has many advantages:

A semantic content model also gives you an advantage in the market. 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. Potential customers could access your content without ever visiting your website.
Beyond those real-world advantages, you’ll also require 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 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.

Consider creating an essay or article. An article’s meaning and usefulness depends upon its parts being kept together. Without the context of the entire article, would one of the headings or paragraphs have any meaning 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 had its headline removed. Because we were dividing content into separate pieces based on layout, content that belonged together became challenging to manage and nearly impossible for multiple delivery channels to comprehend.

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. The content model lacked instincts, so we had to follow our instincts. 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 a variety of content types. 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 a cumbersome editing process and an unnecessary complexity of the model, as well as content that wasn’t understandable by other 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 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. When the design process began, our desire to concentrate on what was visually and historically significant had obscured the purpose of the designs. 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 switch to another format, using tabs, elsewhere. 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 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 the content model was to ensure that it was semantic ( with type and attribute names that reflected the content’s meaning ) and that it kept content together that belonged ( as opposed to separating 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, remember:

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. Without the use of a magic decoder ring, every delivery channel can now consume the content.
You can still use Schema if your team is having trouble making this transition. org–based structured data in your website. The advantage of search engine optimization is a compelling argument on its own, even if additional delivery channels are not in the works.
Remind the team that separating the content model from the design will allow them to update the designs more quickly because they won’t be hindered 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 view content as the most important component of your user experience and as the most effective way to engage with your audience.