有远见的组织采用了全渠道内容战略，其使命是通过多个数字渠道和平台接触受众。
但是，您如何设置内容管理系统 (CMS) 来接触现在和未来的受众？我学到了创建内容模型的艰难方法——一种让人们和系统理解内容的内容类型、属性和关系的定义——用我更熟悉的设计系统思维会颠覆我客户的全渠道内容策略。您可以通过创建语义化并且连接相关内容的内容模型来避免这种结果。
我最近有机会领导一家财富 500 强公司的 CMS 实施。客户对全渠道内容策略的好处感到兴奋，包括内容重用、多渠道营销和机器人交付——将内容设计为机器人、谷歌知识面板、片段和语音用户界面可以理解。
内容模型是全渠道内容策略的关键基础，为了让我们的内容被多个系统理解，该模型需要语义类型——根据其含义而不是其表示来命名的类型。我们的目标是让作者创建内容并在任何相关的地方重复使用它。但是随着项目的进行，我意识到要支持我的客户需要的规模的内容重用，需要整个团队认识到一种新的模式。
尽管我们的意图是最好的，但我们一直在借鉴我们更熟悉的东西：设计系统。与以网络为中心的内容策略不同，全渠道内容策略不能依赖所见即所得工具进行设计和布局。我们倾向于使用我们熟悉的设计系统思维来处理内容模型，这不断导致我们偏离内容模型的主要目的之一：通过多个营销渠道向受众提供内容。
有效内容模型的两个基本原则
我们需要帮助我们的设计师、开发人员和利益相关者了解我们所做的事情与他们之前的 Web 项目非常不同，在这些项目中，每个人都将内容视为适合布局的视觉构建块是很自然的。以前的方法不仅更熟悉而且更直观——至少一开始是这样——因为它让设计感觉更具体。我们发现了两个原则，帮助团队了解内容模型与我们习惯的设计系统有何不同：
- 内容模型必须定义语义而不是布局。
- 内容模型应该连接属于一起的内容。
语义内容模型
语义内容模型使用类型和属性名称来反映内容的含义，而不是如何显示内容。例如，在非语义模型中，团队可能会创建诸如teaser、media blocks和card之类的类型。尽管这些类型可能使内容布局变得容易，但它们无助于交付渠道理解内容的含义，而这反过来又会为每个营销渠道中呈现的内容打开大门。相比之下，语义内容模型使用产品、服务和推荐等类型名称，以便每个交付渠道都可以理解内容并根据需要使用它。
当您创建语义内容模型时，一个很好的起点是查看Schema.org定义的类型和属性，这是一个社区驱动的资源，用于类型定义，Google 搜索等平台可以理解。
语义内容模型有几个好处：
- 即使您的团队不关心全渠道内容，语义内容模型也会将内容与其表示分离，以便团队可以改进网站的设计，而无需重构其内容。通过这种方式，内容可以承受破坏性的网站重新设计。
- 语义内容模型也提供了竞争优势。通过添加基于 Schema.org 的类型和属性的结构化数据，网站可以提供提示以帮助 Google 理解内容，将其显示在搜索片段或知识面板中，并使用它来回答语音界面用户问题。潜在访问者无需踏入您的网站即可发现您的内容。
- 除了这些实际好处之外，如果您想交付全渠道内容，您还需要一个语义内容模型。要在多个营销渠道中使用相同的内容，交付渠道需要能够理解它。例如，如果您的内容模型要提供问题和答案列表，它可以很容易地呈现在常见问题 (FAQ) 页面上，但它也可以用于语音界面或由回答常见问题的机器人使用.
例如，对文章、事件、人员和位置使用语义内容模型，A List Apart可以为搜索引擎提供结构清晰的数据，以便用户可以阅读网站、谷歌知识面板甚至假设的语音界面上的内容在将来。
连接的内容模型
在努力描述什么是好的内容模型之后，我开始意识到最好的模型是那些语义化的并且还连接相关内容组件（例如常见问题解答项目的问答对），而不是分割相关的跨不同内容组件的内容。一个好的内容模型将应该保持在一起的内容连接起来，以便多个交付渠道可以使用它，而无需先将这些部分重新组合在一起。
考虑写一篇文章或论文。一篇文章的意义和有用性取决于它的各个部分被放在一起。如果没有全文的上下文，其中一个标题或段落本身是否有意义？在我们的项目中，我们熟悉的设计系统思维经常导致我们想要创建内容模型，将内容分成不同的块以适应以 Web 为中心的布局。这与将与标题分开的文章产生了类似的影响。因为我们根据布局将内容分割成独立的部分，原本属于一起的内容变得难以管理，并且几乎不可能让多个交付渠道理解。
为了说明这一点，让我们看看连接相关内容如何应用于现实场景。我们客户的设计团队为包含多个选项卡和部分的软件产品页面提供了复杂的布局。我们的直觉是跟随内容模型。难道我们不应该让它尽可能简单和灵活地在未来添加任意数量的标签吗？
因为我们的设计系统直觉如此熟悉，所以感觉我们需要一种称为“标签部分”的内容类型，以便可以将多个标签部分添加到页面中。每个选项卡部分将显示各种类型的内容。一个选项卡可能会提供软件的概述或其规格。另一个选项卡可能会提供资源列表。
我们倾向于将内容模型分解为“选项卡部分”部分，这会导致不必要的复杂模型和繁琐的编辑体验，并且还会创建其他交付渠道无法理解的内容。例如，另一个系统如何能够分辨哪个“选项卡部分”引用了产品的规格或其资源列表 - 其他系统是否必须诉诸于计算选项卡部分和内容块？这将阻止选项卡重新排序，并且需要在每个其他交付渠道中添加逻辑来解释设计系统的布局。此外，如果客户不想再在选项卡布局中显示此内容，
基于设计组件的内容模型不必要地复杂，而且系统无法理解。
当我们发现我们的客户对每个选项卡都有特定的用途时，我们取得了突破：它会显示特定信息，例如软件产品的概述、规格、相关资源和定价。一旦开始实施，我们倾向于关注视觉和熟悉的东西，这掩盖了设计的意图。稍加挖掘，很快就意识到选项卡的概念与内容模型无关。他们计划在选项卡中显示的内容的含义才是最重要的。
事实上，客户本可以决定在其他地方以不同的方式（没有标签）显示这些内容。这种认识促使我们根据客户希望在 Web 上呈现的有意义的属性来定义软件产品的内容类型。既有名称、描述等明显的语义属性，也有截图、软件需求、功能列表等丰富属性。该软件的产品信息保持在一起，因为它没有被分割成单独的组件，例如源自内容演示的“选项卡部分”。任何交付渠道——包括未来的渠道——都可以理解和呈现这些内容。
一个好的内容模型将属于一起的内容连接起来，因此可以轻松管理和重用。
结论
在这个全渠道营销项目中，我们发现保持内容模型正常运行的最佳方法是确保它是语义的（具有反映内容含义的类型和属性名称），并且它将属于一起的内容保持在一起（而不是分割它）。这两个概念减少了我们根据设计塑造内容模型的诱惑。因此，如果您正在开发内容模型以支持全渠道内容策略，或者即使您只是想确保 Google 和其他界面理解您的内容，请记住：
- 设计系统不是内容模型。团队成员可能很想将它们混为一谈，让您的内容模型反映您的设计系统，因此您应该在整个实施过程中保护内容策略的语义价值和上下文结构。这将使每个交付渠道都可以消费内容，而无需魔术解码器环。
- 如果您的团队正在努力实现这一转变，您仍然可以通过在您的网站中使用基于 Schema.org 的结构化数据来获得一些好处。即使额外的交付渠道不在眼前，搜索引擎优化的好处本身就是一个令人信服的理由。
- 此外，提醒团队将内容模型与设计分离将使他们更轻松地更新设计，因为他们不会因内容迁移成本而受阻。他们将能够在不受设计和内容兼容性障碍的情况下创建新设计，并且他们将为下一件大事做好准备。
通过严格倡导这些原则，您将帮助您的团队以应有的方式对待内容——将其视为用户体验中最重要的资产，也是与受众建立联系的最佳方式。
