layers-conceptual-model

/layers-conceptual-model

假设已加载 /layers-intro。此技能是一套技巧库，而非脚本——请参阅其中的“如何使用这些技能”。

概念模型是最常被忽视、却承载着关键内容的一层。它定义产品所识别的对象、对象之间的关系、对象可能处于的状态，以及描述这一切的词汇——这是对产品如何建模其领域所作的审慎决定，与任何界面无关。

它不是用户杂乱的心智模型（那属于领域层），也不是数据库架构、线框图或流程。但这个模型与工程师实际构建的内容之间的差距很重要：未经审视的巨大差距既是 UX 债务（用户面对的产品与模型相矛盾），也是技术债务（系统难以演进）。

---

这一层需要做出的决定

• 产品识别哪些对象，以及每个对象的边界在哪里
• 这些对象之间有什么关系——基数，以及对象担任多个角色时为这些角色命名
• 用户可以对每个对象做什么，或使用每个对象做什么
• 对象可能处于哪些状态，以及哪些状态转换很重要
• 产品的词汇——一个概念对应一个名称，一个名称对应一个概念

如果这些问题都没有真正待定的部分，那么你现在可能不需要这一层。请直接说明，而不是为了做而做。

---

准则——让模型保持准确

无论按什么顺序，都可以将这些准则应用于你产出的内容。它们是这一层中最有价值的部分。

• 只建模真实对象。 真正的对象必须是可实例化的（可以有多个）、有结构的（拥有自己的属性），且有用的（用户本身就关心它）。这能避免两种错误：把属性提升为对象，以及——更常见的——把实例误认为对象：“CAC”和“ROAS”不是对象，而是同一个对象——Metric——的实例。当多个名词属于同一类型时，应将类型建模为对象；具体名称则是实例或取值。
• 真正属于关系的属性。 如果某个属性只是模型中另一个对象的名称或 ID，就应将它建模为关系，而不是重复存储。
• 对象承担多个角色时，为角色命名。 写“属于一个 User（作为推荐人）”，而不是“属于一个 User”。
• 不要臆测添加内容。 每个对象、属性、操作和关系都应能追溯到明确提出的用户需求。在这里扩展范围会影响上方的每一层。（能追溯到策略词汇不算——策略用语还不是对象。）
• 能建模为对象 ≠ 应该一开始就设为一等对象。 “只建模真实对象”这一检验能告诉你某个东西可以成为对象——但不代表产品就应该将它确立为一等、持久且有状态的实体。这样的提升是一项有成本的设计押注。应以具体用途为依据：什么流程或任务要求这个东西必须持久存在、保留状态并被再次访问？ 如果没有这样的用途，它就是临时的，或是为时过早。而如果某个对象的存在完全源于尚未验证的策略押注，就应将其标记为暂定——把它视为假设，不要“定案”，在押注得到验证之前，也不要基于它构建上层。
• 动词要精确。 通用动词（Edit、Delete、Update）是否掩盖了现实后果不同的操作？“Edit address”混淆了更正拼写错误（直接覆盖即可）和记录搬家（应保留历史记录）。当一个通用动词可能表示实质不同的事情时，就应分别命名这些操作——“Correct address”和“Register change of address”并非啰嗦，而是精准。
• 实现不等于设计。 如果讨论开始偏向某个东西如何存储、生成或计算，就应将话题引回用户可以做什么，以及引用该对象的内容会发生什么。对于确实与实现紧密交织的问题，应标记出来，留待与工程团队讨论，而不是过早强行给出答案。

---

技法

根据当前需要做出的决策选择合适的技法——不要全部都用。

技法	用途
名词搜集 + OOUX（Sophia Prater）	从研究资料或领域笔记中提取对象。当你需要从自然语言材料中挖掘信息时，这是默认选择。根据上文的“仅保留真实对象”测试，将名词分为对象／属性／实例或取值／暂不纳入（UI 元素、含糊的抽象概念、伪装成名词的操作）。
对象定义	明确一个对象：它是什么（用一句话描述，从用户视角出发）、它的属性、它的关系（基数 + 角色名称）以及它的操作。
先勾勒流程（向前推演，向后回溯）	对象性尚不确定——某样东西是否应成为持久对象，取决于它的使用方式。先用面包板法梳理流程（/layers-interaction-flow），看看哪些内容必须持久存在、保存状态或可供用户返回，然后再回来，只对这些内容进行正式建模。这通常是区分真实对象与临时对象最快的方法。
关系对象图（erDiagram）	一起查看对象及其关系，找出缺失、颠倒或多余的连接。||=恰好一个，o{=零个或多个，|{=一个或多个；乌鸦脚放在“多个”一侧；标签按第一个实体 → 第二个实体的顺序读取。
状态转换图（stateDiagram-v2）	适用于状态变化会影响用户操作的对象——列出状态、状态转换，以及每个状态禁止的操作。
操作（CTA）清单	将用户可执行的所有操作跨对象汇总在一处——形成产品的行动号召词汇表。把它们放在一起列出（而不是按对象逐一列出），才能发现不一致（同一种操作有 Add、Create、New 等不同说法）和过度扁平化（一个动词掩盖了不同的操作）。
通用语言清单	统一命名。对每个有争议的概念，记录选定的术语、舍弃的备选词及原因。每个概念只用一个名称，每个名称只表示一个概念——在 UI、帮助文本、API 名称和内部交流中都保持一致。
语义 IxD／操作语法（Rosenberg）	审查多个操作和对象之间动词使用的一致性与准确性。
事件风暴——命令／策略（Brandolini）	适用于流程繁重的领域：从发生的事情入手，反向梳理涉及的对象。
卡片分类	用户或团队对词汇的理解不清楚或存在分歧。
走查现有产品	适用于重新设计：当前 UI 展现了隐含模型——将其与用户的实际思维方式进行比较。

对于任何存在相关问题的对象，也要探查 /layers-intro 中的时间性决策——中间操作状态、读取模型延迟、关系的时间性、删除语义和历史记录。

---

与设计师协作

找出上述哪些决策当前需要解决。提出合适的技法：有材料可挖掘时用名词搜集，重新设计时走查产品，若对象已知且只需确定其形态，则直接进行对象定义。只做下一步有用的事，不要把整套工具都用一遍。

只记录最终留下的内容——已敲定的对象定义（以及仍属暂定、有待验证假设或流程梳理的定义）、能体现真实关系或生命周期的图表、术语决策和待解决的问题（定义仍不扎实的对象、留待工程团队决策的事项）。不要写设计师不会重读的报告。

如果尚未开展领域研究，请直言：在有证据之前，这个模型只是假设。

当对象和操作稳定后，下一步自然是设计用户如何在它们之间流转——/layers-interaction-flow。