writing-specs-designs

编写规格说明和设计方案

适用范围

涵盖内容

• 产出一套规格说明和设计文档包，帮助产品、设计和工程团队快速达成共识
• 将“洞察”转化为具体产物：低保真图示、流程／状态、原型计划和可测试的验收标准
• 移动端专属的点击成本优化（适用时）：明确优化点击次数和交互成本

适用场景

• “为这个功能编写规格说明／功能规格说明／技术规格说明。”
• “把这些笔记整理成一份工程团队可以据此构建的设计文档。”
• “创建一份塑形风格的文档，并附上展示各组成部分的图示。”
• “我们需要一份原型计划来评估这种交互的体验。”

不适用场景

• 你仍在验证要解决什么问题（应先开展探索／问题定义）。
• 你需要高层战略／愿景文档（应先开展产品愿景／北极星指标相关工作）。
• 你需要深入的工程架构设计（API、模式、扩展能力、可靠性），而非明确产品交互。
• 你只需要像素级精准的 UI 模型（这里产出的是规格说明和结构化指导，而非最终视觉稿）。

输入

最低要求

• 功能／变更：1–2 句话描述
• 目标用户 + 主要使用场景（顺利路径）
• 平台：web／iOS／Android／桌面端（请明确指出移动端）
• 目标 + 非目标（v1 范围边界）
• 约束：时间线、依赖项、政策／法律／隐私、技术约束
• 成功指标（1–3 个）+ 护栏指标（2–5 个）

缺少信息时的处理策略

• 从 references/INTAKE.md 中提出最多 5 个问题，然后继续。
• 如果仍缺少关键信息，请明确说明假设，并提供 2–3 个选项（范围／流程／原型方案）。

输出（交付物）

以 Markdown 形式产出一套规格说明和设计文档包（在对话中提供；如用户要求，也可提供为文件）：

1. 背景概览（问题、为何是现在、目标／非目标、约束、利益相关者）
2. 展示各组成部分的低保真图示（≤10 个）+ 关键决策
3. 用户流程 + 状态（顺利路径 + 主要边缘情况），并明确入口／出口
4. 原型简介（原型内容、保真度、时间限制、数据真实性、成功标准）
5. 需求 + 验收标准（可测试；必须／应该／可以）
6. 衡量计划（指标 → 数据／事件 → 负责人 → 频率）
7. 风险／待解问题／后续步骤（始终包含）

模板：references/TEMPLATES.md

工作流程（8 步）

1) 选择能为团队扫清障碍的最小产物集

• 输入： 用户请求 + 约束。
• 操作： 决定交付：(a) 仅规格说明和设计文档，或 (b) 规格说明和设计文档 + 重点突出的原型简介（交互体验至关重要时）。
• 输出： 产物选择 + 理由。
• 检查： 产物符合当前需要作出的决策（达成共识、执行构建或评估交互体验）。

2) 收集信息 + 编写背景概览

• 输入： references/INTAKE.md。
• 操作： 提出最多 5 个问题；确认受众／DRI、平台、约束以及成功指标／护栏指标。
• 输出： 背景概览章节。
• 检查： 能在 1–2 句话内说明问题、用户和衡量成功的方式。

3) 明确范围边界（移动端需定义“点击预算”）

• 输入： 背景概览。
• 操作： 写明目标、非目标、范围外事项、假设和依赖项。对于移动端流程，定义“点击预算”（到达价值所需的最大点击次数），并指出最容易分散注意力的环节。
• 输出： 范围边界 +（可选）点击预算。
• 检查： 明确说明“我们不做什么”；移动端价值路径有清晰的点击目标。

4) 起草低保真图示（“塑造”阶段的产出）

• 输入： 范围 + 约束。
• 操作： 绘制图示，呈现各个组成部分（≤10 个）、数据流/交接点，以及 UX 决策的重要之处。避免细化到像素级 UI；优先保证结构清晰。
• 输出： 低保真图示 + 已注释的决策。
• 检查： 合作者无需开会就能说“我知道要构建什么”。

5) 明确用户流程 + 状态（将边缘情况具体化）

• 输入： 图示 + 用例。
• 操作： 记录入口、顺利路径和主要边缘情况；纳入错误/空白/加载状态、权限，以及在措辞不明确会导致错误的地方添加文案说明。
• 输出： 流程 + 状态表。
• 检查： 他人可以模拟整个流程；每种边缘情况都有预期结果。

6) 撰写原型简报（仅在“感受”很重要时）

• 输入： 流程/状态 + 未知因素。
• 操作： 找出风险最高的 1–3 个交互不确定因素；说明原型类型（低保真、高保真或代码实现）、时间限制、真实程度（尽可能使用真实数据），以及理想的“良好”体验。
• 输出： 原型简报。
• 检查： 原型计划可测试（包含场景 + 成功标准）；如果使用一次性代码，要明确说明原型可随时丢弃。

7) 转化为可测试的需求 + 验收标准

• 输入： 流程/状态 + 原型带来的经验（如有）。
• 操作： 编写包含验收标准的需求（必须/应该/可以）。纳入非功能需求（无障碍、性能、隐私）和埋点需求。
• 输出： 需求章节。
• 检查： 工程/QA 团队无需重新解读意图，就能据此编写测试用例。

8) 质量检查 + 定稿以便传阅

• 输入： 完整的草稿包。
• 操作： 使用 references/CHECKLISTS.md 检查，并依据 references/RUBRIC.md 评分。添加风险/待解决问题/后续步骤，并清楚标明决策与假设。
• 输出： 最终规格说明与设计文档包（可直接分享）。
• 检查： 负责人、指标和待解决问题都清晰明确；图示 + 流程消除了最大的歧义。

质量检查（必需）

• 使用 references/CHECKLISTS.md 和 references/RUBRIC.md。
• 始终包含：风险、待解决问题、后续步骤。

示例

示例 1（移动端流程）：“为我们的 iOS 应用中的新‘邀请好友’流程撰写规格说明 + 设计文档。目标：增加成功邀请次数；尽量减少用户首次获得价值前所需的点击次数。”
预期：点击次数上限 + 流程/状态表、展示屏幕/跳转关系的低保真图示，以及针对关键交互的原型简报。

示例 2（B2B Web 功能）：“为管理员的‘批量编辑角色’功能撰写设计文档/规格说明。纳入边缘情况和验收标准。”
预期：侧重权限的流程/状态、包含验收标准的需求，以及衡量计划。

边界示例：“撰写一份‘提升参与度’的规格说明（没有产品背景、用户或成功指标）。”
回应：提出最少量的背景收集问题；如果仍然缺少信息，则提供 2–3 个范围明确的选项 + 假设，并建议先开展上游探索，再着手制定规格说明。