内容模型不是设计系统

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

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

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

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

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

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

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

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

语义内容模型#section3

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

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

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

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

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

连接的内容模型#section4

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

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

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

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

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

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

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

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

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

结论#section5

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

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

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