内容模型不是设计系统

你是否还记得曾经拥有一个优秀网站就足够的时代？现在人们从Siri、Google搜索摘要和移动应用获取答案，而不仅仅是通过我们的网站。具有前瞻性思维的组织已采用全渠道内容策略，其使命是通过多个数字渠道和平台触达受众。

但如何设置内容管理系统（CMS）以现在和未来触达受众？我艰难地认识到，用我更熟悉的设计系统思维创建内容模型——即定义内容类型、属性和关系，使人和系统能够理解内容——会颠覆客户的全渠道内容策略。通过创建语义化且连接相关内容的内容模型，你可以避免这种结果。

我最近有机会领导一家财富500强公司的CMS实施。客户对全渠道内容策略的好处感到兴奋，包括内容重用、多渠道营销和机器人交付——设计内容以便机器人、Google知识面板、摘要和语音用户界面能够理解。

有效内容模型的两个基本原则#section2

我们需要帮助设计师、开发人员和利益相关者理解，我们正在做的事情与他们之前的Web项目非常不同，在这些项目中，每个人自然地将内容视为适合布局的视觉构建块。之前的方法不仅更熟悉，而且更直观——至少最初是这样——因为它使设计感觉更具体。我们发现了两个原则，帮助团队理解内容模型与我们习惯的设计系统的不同之处：

• 内容模型必须定义语义而不是布局
• 内容模型应该连接属于一起的内容

语义内容模型#section3

语义内容模型使用反映内容含义的类型和属性名称，而不是它将如何显示。例如，在非语义模型中，团队可能会创建诸如预告片、媒体块和卡片等类型。尽管这些类型可能使内容布局变得容易，但它们无助于交付渠道理解内容的含义，这反过来又会为内容在每个营销渠道中的呈现打开大门。相比之下，语义内容模型使用产品、服务和推荐等类型名称，以便每个交付渠道都能理解内容并按需使用。

创建语义内容模型时，一个很好的起点是查看Schema.org定义的类型和属性，这是一个社区驱动的类型定义资源，可供Google搜索等平台理解。

语义内容模型有几个好处：

即使你的团队不关心全渠道内容，语义内容模型也将内容与其呈现解耦，以便团队可以在不需要重构其内容的情况下发展网站设计。这样，内容可以承受破坏性的网站重新设计。 语义内容模型还提供了竞争优势。通过添加基于Schema.org类型和属性的结构化数据，网站可以提供提示以帮助Google理解内容，在搜索摘要或知识面板中显示它，并用它来回答语音界面用户问题。潜在访问者可能无需踏入你的网站即可发现你的内容。 除了这些实际好处之外，如果你想交付全渠道内容，还需要一个语义内容模型。为了在多个营销渠道中使用相同的内容，交付渠道需要能够理解它。例如，如果你的内容模型提供问题和答案列表，它可以轻松地在常见问题（FAQ）页面上呈现，但也可以用于语音界面或回答常见问题的机器人。

例如，对文章、事件、人物和位置使用语义内容模型，让A List Apart为搜索引擎提供清晰的结构化数据，以便用户可以在网站、Google知识面板上阅读内容，甚至在未来使用假设的语音界面。

连接的内容模型#section4

在努力描述什么是一个好的内容模型之后，我意识到最好的模型是那些语义化并且还连接相关内容组件（例如FAQ项目的问题和答案对）的模型，而不是将相关内容分割到不同的内容组件中。一个好的内容模型连接应该保持在一起的内容，以便多个交付渠道可以使用它，而无需首先将这些部分重新组合在一起。

考虑写一篇文章或论文。一篇文章的含义和有用性取决于其部分保持在一起。在没有完整文章上下文的情况下，其中一个标题或段落本身会有意义吗？在我们的项目中，我们熟悉的设计系统思维经常导致我们想要创建将内容分割成不同块以适合以Web为中心的布局的内容模型。这产生了与文章与其标题分离类似的影响。因为我们基于布局将内容分割成独立的部分，属于一起的内容变得难以管理，并且几乎不可能被多个交付渠道理解。

为了说明这一点，让我们看看连接相关内容在现实场景中的应用。我们客户的设计团队提出了一个软件产品页面的复杂布局，包括多个标签页和部分。我们的本能是用内容模型效仿。我们不应该尽可能容易和灵活地将来添加任意数量的标签页吗？

因为我们的设计系统本能如此熟悉，感觉我们需要一个称为“标签部分”的内容类型，以便可以向页面添加多个标签部分。每个标签部分将显示各种类型的内容。一个标签可能提供软件的概述或其规格。另一个标签可能提供资源列表。

我们将内容模型分解为“标签部分”部分的倾向会导致不必要的复杂模型和繁琐的编辑体验，并且还会创建无法被其他交付渠道理解的内容。例如，另一个系统如何能够判断哪个“标签部分”指的是产品的规格或其资源列表——另一个系统是否必须依靠计算标签部分和内容块？这会阻止标签重新排序，并且需要在每个其他交付渠道中添加逻辑来解释设计系统的布局。此外，如果客户不再希望以标签布局显示此内容，迁移到新的内容模型以反映新的页面重新设计将是繁琐的。

基于设计组件的内容模型是不必要的复杂，并且系统无法理解。

当我们发现客户对每个标签都有特定目的时，我们取得了突破：它将揭示特定信息，如软件产品的概述、规格、相关资源和定价。一旦实施开始，我们关注视觉和熟悉事物的倾向掩盖了设计的意图。通过一点挖掘，很快意识到标签的概念与内容模型无关。他们计划在标签中显示的内容的含义才是重要的。

事实上，客户可能决定以不同的方式——没有标签——在其他地方显示此内容。这一认识促使我们根据客户希望在Web上呈现的有意义的属性为软件产品定义内容类型。有明显的语义属性，如名称和描述，以及丰富的属性，如截图、软件要求和功能列表。软件的产品信息保持在一起，因为它没有被分割成诸如从内容呈现衍生的“标签部分”之类的单独组件。任何交付渠道——包括未来的渠道——都可以理解并呈现此内容。

一个好的内容模型连接属于一起的内容，以便可以轻松管理和重用。

结论#section5

在这个全渠道营销项目中，我们发现保持内容模型正常进行的最佳方式是确保它是语义化的（具有反映内容含义的类型和属性名称）并且它将属于一起的内容保持在一起（而不是碎片化）。这两个概念遏制了我们基于设计塑造内容模型的诱惑。因此，如果你正在开发一个内容模型以支持全渠道内容策略——或者即使你只想确保Google和其他界面理解你的内容——请记住：

• 设计系统不是内容模型。团队成员可能倾向于混淆它们并使你的内容模型镜像你的设计系统，因此你应该在整个实施过程中保护内容策略的语义价值和上下文结构。这将让每个交付渠道使用内容，而无需神奇的解码环。
• 如果你的团队正在努力进行这种转变，你仍然可以通过在网站中使用基于Schema.org的结构化数据获得一些好处。即使额外的交付渠道不在眼前，对搜索引擎优化的好处本身就是一个令人信服的理由。
• 此外，提醒团队将内容模型与设计解耦将让他们更轻松地更新设计，因为他们不会受到内容迁移成本的阻碍。他们将能够创建新设计，而没有设计与内容兼容性的障碍，并且他们将准备好迎接下一个大事。

通过严格倡导这些原则，你将帮助团队以应有的方式对待内容——作为用户体验中最关键的资产和与受众联系的最佳方式。