内容模型不是设计系统

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

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

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

内容模型是全渠道内容战略的关键基础，为了让多个系统理解我们的内容，模型需要语义类型——根据其含义而非呈现方式命名的类型。我们的目标是让作者创建内容并在相关的地方重用它。但随着项目的进行，我意识到支持客户所需规模的内容重用需要整个团队认识到一种新模式。

尽管我们意图良好，但我们不断借鉴我们更熟悉的东西：设计系统。与以网络为中心的内容战略不同，全渠道内容战略不能依赖WYSIWYG工具进行设计和布局。我们倾向于用熟悉的设计系统思维处理内容模型，这不断导致我们偏离内容模型的主要目的之一：通过多个营销渠道向受众传递内容。

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

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

内容模型必须定义语义而非布局。
内容模型应连接属于一起的内容。

语义内容模型

语义内容模型使用反映内容含义的类型和属性名称，而不是如何显示。例如，在非语义模型中，团队可能会创建 teasers、media blocks 和 cards 等类型。尽管这些类型可能使内容布局变得容易，但它们无助于交付渠道理解内容的含义，而这本可以为内容在每个营销渠道中的呈现打开大门。相比之下，语义内容模型使用 product、service 和 testimonial 等类型名称，以便每个交付渠道都能理解内容并按需使用。

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

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

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

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

连接的内容模型

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

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

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

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

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

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

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

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

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

结论

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

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

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