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