设计交接简报技能

产出一份设计简报，为设计师的成功奠定基础——在他们打开 Figma 之前，就帮助其充分理解用户场景与约束条件，而非等到已误入歧途之后才补救。

必需输入项

若用户未主动提供，请向其明确索取以下内容：

• 功能简报或 PRD（即使是粗略笔记也可接受）
• 设计师姓名或所属团队（用于个性化定制）
• 技术约束（目前已知的工程限制）
• 时间线（设计需何时完成？）

设计师真正需要的内容（而产品经理常忽略的部分）

• 用户的**目标**，而非功能名称
• 用户在此旅程节点所处的**情绪状态**
• **成功的表现形式**——我们如何判断该设计真正奏效？
• 各类**约束条件**：技术、法律、品牌、无障碍访问（Accessibility）
• 必须被处理的**边缘情况（Edge Cases）**
• 我们**明确不解决的问题**

执行流程

1. 通读所提供的功能简报或 PRD
2. 提炼用户目标（将功能语言重新表述为以用户结果为导向的语言）
3. 识别各项约束——包括技术限制、品牌规范、无障碍访问要求
4. 列出设计必须覆盖的边缘情况
5. 定义用于评估设计成效的**成功标准**
6. 撰写“**明确不在范围内**”（Explicitly Out of Scope）章节，防止设计范围蔓延（Scope Creep）
7. 验证——确认所列每项边缘情况均具备足够具体性，可供实际设计；每一项“不在范围内”的条目也须足够明确，能清晰说“不”

输出结构

设计简报：[Feature Name]

用户目标：（使用用户自己的语言表达，而非我们的术语）
“当我 [所处情境] 时，我希望 [动机]，以便我能 [最终结果]。”

上下文与情绪状态：
[用户当前处于其旅程中的哪个阶段？他们正感受什么？刚刚发生了什么？]

设计成功标准：

• [标准 1 — 尽可能量化]
• [标准 2]
• [标准 3]

约束条件：

• 技术层面：[工程团队已指出的限制]
• 品牌层面：[相关品牌规范]
• 无障碍访问（Accessibility）：[所需 WCAG 等级，及其他具体要求]
• 法律/合规层面：[如适用]

需覆盖的边缘情况：

• [边缘情况 1]
• [边缘情况 2]
• [边缘情况 3]

明确不在范围内：

• [本次设计迭代中我们不解决的问题]

参考材料：

• 用户研究：[链接]
• 现有模式：[Figma 组件库链接]
• 竞品示例：[如相关，附链接]

质量校验清单

• 用户目标使用的是用户语言（而非功能/产品语言）
• 至少有一项边缘情况涵盖错误或失败状态
• 成功标准可衡量或可观测（不能是“看起来不错”这类主观描述）
• “不在范围内”章节至少明确列出一项看似应属范围内、实则并非本次目标的内容
• 技术约束足够具体，工程师可据此准确确认其真实性

反模式（应避免的做法）

• 不得以功能语言撰写用户目标（例如“设计结账流程”）——必须从用户视角出发，包含动机与结果
• 不得省略“明确不在范围内”章节——缺少该章节，设计师将无意中解决本不属于本次迭代的问题
• 不得罗列过于泛化的边缘情况（例如“处理错误”）——每一项边缘情况都必须针对该功能特有的失效模式而设定
• 在未确认工程约束是否准确前，不得移交简报——错误的约束比没有约束更危险
• 不得忽略用户的情绪背景——缺乏情绪锚点的设计，即便技术上正确，体验上也往往平淡乏味