layers-user-needs

/layers-user-needs

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

用户需求是我们对用户试图实现什么及其原因的判断——这种解读基于观察到的行为和领域知识，而非对现实的直接记录。这一层位于杂乱的原始观察材料与解决方案空间中的审慎决策之间。

这里的产出是机会：需求（用户想要实现什么）、痛点（造成阻碍的因素）和愿望（用户认为有价值的改进）。这三者都成立——应当一并挖掘。

---

这一层要做出的决策

• 我们界定需求的用户究竟是谁——以及他们处于什么情境
• 他们试图完成哪些任务：功能性、情感性和社交性任务
• 哪些需求有证据支撑，哪些只是推测
• 哪些需求最重要，以及原因

如果需求已经明确且有依据，就不要为了走流程而重新挖掘——将其带入 /layers-product-strategy。

---

原则——确保需求真实可靠

• 关注需求，而非解决方案。“我需要报告时，希望能导出为 CSV”描述的是解决方案。应深入探究其背后的需求。
• **剔除实现机制。**如果“When”部分提到了你的具体解决方案（你的仪表盘、你的 CSM、你的每周邮件），你描述的就是当前系统，而非需求。请改为不依赖由谁或什么来满足需求的表述：用户在需要这项帮助时，处于什么状态？ 需求源于状态，而非实现机制。
• **“When”必须具体可想象。**应具体到能看见事情发生的那一刻——由某个事件、感受、节奏或达到的阈值触发。继续追问，直到足够具体。
• **挖掘情感和社交任务，不要只关注功能任务。**即便它们正在影响行为，也常常长期缺乏清晰表述。明确询问通常才能将其挖掘出来。（功能 → 交互与模型；情感 → 界面基调与反馈；社交 → 界面，有时也涉及策略。）
• **标明置信度：**观察所得／推断所得／假设。
• **变通做法是重要信号。**如果某项需求足以促使用户制作电子表格或发送变通邮件，那它就很可能是一项强需求。

---

技巧

工作任务故事是默认方法；其他方法适用于特定情况。

技巧	适用场景
工作任务故事（JTBD）	默认方法。*当[情境]时，我想要[动机]，以便[结果]。*避免引入解决方案；“When”部分会促使表述更具体。
用户故事	团队偏好以角色为基础的表述，或已有敏捷工作流时。
高频任务分析（Gerry McGovern）	用户群体规模较大的现有产品——通过任务频率找出最重要的任务。基于统计和调查。
用户画像 + 场景	面向习惯用典型角色思考的利益相关者进行沟通。适合达成共识，但对设计而言不够精确。
ODI 期望结果（Ulwick）	精确、可衡量的表述——“在[情境]下，将[指标]降至最低。”可直接用于机会评分。
挖掘隐藏需求	用提示找出被忽略的内容：用户在你关注的时刻之前或之后会做什么；他们希望不必做什么；当前的变通做法满足了什么需求。
粗略确定优先级	按重要性 × 当前满足程度排序。一项重要且当前满足得不好的需求，就是高价值机会。保持粗略——精确评分属于策略工作。

---

与设计师合作

首先确定用户是谁、处于什么情境——不要只说“用户”，而要明确是哪类用户、何时使用。如果有多个需求不同的明确类型，就分别处理。注明信息来源（研究、领域知识或假设）；如果是假设，请标明并制定验证计划。

然后通过上述各学科梳理设计师提出的需求，并探查隐藏需求。选择合适的技术——默认使用工作任务故事，重视可衡量性时使用 ODI，用户群体庞大时使用核心任务。不要按固定顺序执行。

只记录最终要点：已排序并标注置信度的需求、已发现但未排序的需求（以免遗漏）、空白之处（可能真实存在但尚无依据的需求），以及不同用户类型之间的矛盾。只保留影响决策的内容。

这些需求是 /layers-product-strategy 的机会点。如果大多数需求都只是推测，可以考虑使用 /layers-observed-behaviour 收集证据，再据此制定策略。