design-thinking

设计思维

爱上问题，而不是第一个解决方案。最后要明确接下来要了解什么，而不只是列出想法。

适用场景

• 产品、服务或 UX 问题，真正的用户需求尚不明确。
• 使用「我们如何才能」的表述、开展探索冲刺，或在开发前验证概念。
• 根据用户的实际行为或说法，重新界定需求。

不适用：规格已完全定稿且不需要探索，或任务只是代码维护，没有需要界定的用户问题。

开始之前

1. 在一个区块中说明：设计挑战（谁受到影响，处于什么情境）和通过标准（共情、定义、构思、原型、测试计划）。
2. 先收集信息。 在撰写共情阶段之前，先阅读工单、访谈记录、支持帖、分析数据或产品本身。只有当工具无法回答有关用户、约束或成功信号的问题时，才提出问题，最多 3 个。
3. 轻量路径。 小型需求：每个阶段写 1-2 行、提出 3 个想法、制作一个原型、设定 2 个信号。
4. 如果共情阶段没有真实的用户输入，就在定义阶段说明这一点，并将 POV 限定在较小范围内。绝不编造研究结果。

阶段

1. 共情

• 对象： 主要用户或利益相关者。将用户提供的事实与 [INFERRED] 区分标注。
• 任务、痛点、收益： 他们想做什么，遇到了哪些困难。
• 情境： 需求在何时、何地出现。

不要捏造引语。仅转述用户提供的信息。

2. 定义

• 洞察： 将痛点与情境联系起来的、非显而易见的矛盾。
• POV： 「[用户] 需要**[动词]，因为[洞察]**。」
• 我们如何才能： 提出 2-3 个范围明确、由 POV 引出的问题。

3. 构思

以每个 HMW 作为提示词，提出数量充足且多样的想法。将每个想法标记为 desirable、feasible 或 viable，并明确这些是假设，而非事实。默认提出 8-10 个想法，除非用户指定数量。

4. 原型

描述低保真产物：纸上流程、角色扮演脚本、落地页冒烟测试、可点击草图。每个产物都要说明：**目的：**它要回答的问题。**保真度：**用一行说明其处于仅草图与交互式原型之间的哪个位置。

5. 测试计划

• 学习目标： 哪些结果会让你相信这个想法是错的？
• 参与者： 参与者是谁、人数多少，或者写「待定」。
• 信号： 要观察的行为或指标，并明确指出哪些结果会证伪想法。
• 下一轮迭代： 如果结果不明确，要如何调整。

常见问题

• POV 只是复述解决方案（「用户需要一个仪表板」）。
• HMW 问题范围太广（「改善体验」）或太窄（暗中限定了解决方案）。
• 将 desirable / feasible / viable 标签当作已证实的结论。
• 测试计划中没有能表明想法错误的信号。

示例：references/example.md。

检查清单

• 已说明挑战和通过标准
• 共情阶段将事实与 [INFERRED] 区分开
• 在构思前已明确 POV 和 HMW
• 将想法标记为 desirable、feasible 或 viable，并注明是假设
• 原型说明了目的和保真度
• 测试计划包含学习目标和可证伪的信号