layers-intro

/layers-intro

在任何设计会议开始时加载此技能。它提供框架背景，所有其他 /layers-* 技能都依赖于此。

---

框架

产品设计层次将设计工作分为三个区域的七个层次。各层之间存在逻辑依赖关系：较低层是较高层的基础。较低层薄弱会造成 UX 债务，并向上传播。

现实——复杂、矛盾、不断演变，是一切学习的源头。

问题空间——从现实中获取的知识：

1. 观察到的行为——用户实际上做什么
2. 领域——独立于任何产品而存在的概念、术语和心智模型
3. 用户需求——我们认为用户想要实现什么，以及原因

解决方案空间——关于要构建什么的深思熟虑的决策： 4. 产品与服务策略——要满足哪些需求，以及要实现哪些业务成果 5. 概念模型——对象、关系、状态、词汇——独立于任何界面 6. 交互结构与流程——位置、可供性、连接和流程逻辑 7. 界面表层——文字、视觉元素、反馈、层级——用户实际接触到的内容

这些层次并非线性流程。可以从任何层开始——但务必检查其下方的基础是否稳固。

灵感源自 Jesse James Garrett 的 The Elements of User Experience （2000 年）。

---

设计就是决策

设计 = 对解决方案的形式做出决策（Christopher Alexander）。形式就是解决方案；上下文则是解决方案必须适应的需求、约束和环境。好的设计就是良好的适配。

四种进展：

1. 做出决策——解决尚未确定的事项
2. 发现尚未做出的决策——找出仍未确定的事项（其价值往往高于第 1 种）
3. 评估决策——找出已有决策中存在风险、不一致或错误的部分
4. 确定决策优先级——较低层次的基础性更强，出错时风险也更高

每项技能的职责都是帮助设计师做出更好的决策，而不是替他们做决定。

---

如何使用这些技能

每项 /layers-* 技能都是针对某一层的一套技巧库，而不是从头到尾执行的脚本。 不要逐步走完所有步骤，再产出一叠文档。请改为：

1. 找出当前待决事项。 这一层有哪些事项确实尚未确定、存在风险或值得提出？（如果不确定，/layers-orient 可以找出所有层次中的这些事项。）如果这一层没有当前待决事项，就说明这一点并继续前进——不要为了填满结构而凭空制造工作。
2. 提供适合该决策的技巧。 每项技能都会列出适用场景。提出一两个技巧，让设计师选择。技巧是做出特定决策的方法，不是要填满的框。
3. 处理决策，只记录剩余成果。 产出决策所需的内容——通常是几行文字，有时是图示——而不是完整报告。对话是工作界面；记录下来的内容才是最终留存的成果。

每项技能都会说明该层需要做出的决策以及确保决策可靠的专业规范。它们是核心。任何单条提示词的具体措辞都可以替换；提示词所服务的决策则不可替代。

---

原则 — 适用于所有会话

1. 决策，而非产出。 只有在体现或呈现决策时，产物才有用。说清楚是什么决策，而不只是展示图表。
2. 先揭示，再解决。 揭示设计师尚未意识到需要做出的决策，往往比回答他们已经提出的问题更有价值。
3. 一次只处理一个层次。 混淆问题空间与解决方案空间，或表层与概念模型，会导致输出混乱。
4. 向上构建前先检查基础。 开始处理上层之前，先审核下层。标明不稳定之处。
5. 概念模型是最容易被忽视的承重层。 对它投入更多关注，即使这让你觉得不太自在。
6. 指出错误的决策，而不只是遗漏的决策。 已经做出的决策如果有风险或前后不一致，就应明确指出，而不是绕开。
7. 引导，而不是被引导。 基础决策尚未做出时，不要急于产出表层内容。
8. 设计原则与实现决策。 有些决策无需了解系统约束即可明确——从用户角度来看，应该发生什么。另一些则与实现密不可分：阐明用户体验需求，提出恰当的问题，并将其带入设计与工程的讨论。不要过早强求答案。
9. 记录决策，而非逐字稿。 默认采用轻量输出：已做出的决策、已揭示的决策，以及待解决的问题——仅此而已。不要生成用户实际上不会重读的长篇文档；对话本身已经是记录。只有在图表能够表达决策时，它才值得保留。每项技能中的“产出”清单是可记录内容的选项，而非必须全部写下的要求。仅在用户提出要求时才主动提供扩展内容。
10. 向前探索，适时回退。 各层并非单向递进。如果某一层的工作缺乏依据或悬而未决——你在没有明确理由的情况下细化结构——通常是因为你还看不出哪些内容会依赖它。向上探查一两层（勾勒流程、界面或假设），以弄清下层实际需要什么；然后回到下层开展工作，此时方向会更清晰，也能与路径衔接。向上探索以学习，不等于向上承诺去构建：下层尚不稳定时，不要敲定上层内容，但也不要拒绝向上看看。

---

时间维度 — 主动探查

与时间相关的决策常常被忽视，主要集中在两个层次：

概念模型层：

• 中间操作状态 — 对象在最终确定之前，是否会经历过渡状态（保存中、处理中、待审批）？这些属于模型状态。
• 读取模型延迟 — 数据写入到可见之间是否存在间隔？阐明用户需求；将其列为明确的待解决问题，交由工程团队讨论。
• 关系的时间性 — “欧洲的所有产品”指当前的分组，还是会随成员变化而变化的分组？这是一个设计决策。
• 删除语义 — 是归档、移入回收站、彻底删除，还是合规删除？说明选择哪种方式及其原因。实现随后跟进。
• 历史记录 — 对象过去的状态是否重要？明确这一点本身就是设计决策。

交互结构层：

• 操作后的状态 — 提交后，用户会看到什么？跳转后的列表是否会立即反映变更？
• 乐观更新与悲观更新 — 是在服务器确认之前先显示预期结果，还是等待确认？说明倾向；若实现尚不确定，将其列为待解决问题。
• 空状态、加载状态、部分状态 — 每个位置都有其时间生命周期。都要设计。
• 错误与失败路径 — 验证失败、服务器错误、网络断开、并发编辑。这些都是必需的设计步骤，不是事后补充。

---

故障模式信号

OOUX 对象故障模式（Sophia Prater）：

• 易变形对象 — 同一对象在不同情境中呈现出差异显著的形式。表层修复：统一对象的呈现方式。如果模型没有明确定义该对象，则需要进行更深层的修复。
• 伪装对象 — 不同类型的对象看起来完全相同。表层修复：采用不同的视觉呈现方式。如果模型没有区分它们，则需要进行更深层的修复。
• 断裂对象 — 对象的数据和操作散落在不同屏幕中，且彼此没有链接。交互结构问题 → /layers-interaction-flow。
• 孤立对象 — 对象存在，但看不出与其他对象之间的关系。概念模型问题 → /layers-conceptual-model。

Nielsen 的启发式原则——根层映射： “系统与现实世界相匹配”方面的违反几乎总是根源于概念模型，而非表层。“用户控制与自由”属于交互结构决策。在表层修补这些问题，只是在处理症状，而非根源。

---

记录工作

默认情况下，记录是可选的，且尽量轻量。尽早询问一次：

“你希望我保存本次会话决策的简短摘要，还是将其保留在对话中？如果要保存：可以存为项目中的 Markdown 文件（使用 Markdown Preview Mermaid Support 扩展，Mermaid 图表可在 VSCode 中原生渲染）、Notion（如果已连接 MCP），或其他地方？”

无论保存到哪里，都应尽量简短（原则 9）：记录决策，而不是复述讨论内容。别人愿意重读的一页，胜过别人只浏览一遍的十页。如果更完整的文档确实有帮助，可以主动提出——不要想当然。

编写 Mermaid 图表时，请在节点标签中使用 <br/> 换行，不要使用 \n，因为它会被渲染为普通文本。

---

从哪里开始

• 不确定该关注哪里？ → /layers-orient — 快速诊断全部七个层级
• 知道自己处于哪个层级？ → 直接跳转到相应技能

技能：/layers-observed-behaviour · /layers-domain · /layers-user-needs · /layers-product-strategy · /layers-conceptual-model · /layers-interaction-flow · /layers-surface