第2章 用户场景挖掘与问题定义：场景卡片法、用户故事地图、从痛点出发定义业务问题
用户场景是 PRD 撰写的起点。没有场景的需求是空中楼阁，脱离情境的功能注定无人使用。本章围绕三种核心方法——场景卡片法、用户故事地图和从痛点定义业务问题——构建一条从「真实情境」到「可验证问题」的完整链路，为后续需求拆解与原型设计奠定用户视角的基石。
2.1 场景卡片法：捕获真实使用情境
场景卡片是一种轻量级结构化工具，用一张卡片记录一个用户在某特定情境下的完整行为片段。它强迫团队用「谁、在哪、做什么、为什么」的视角观察用户，而非直接跳入功能列表。
四要素模型
| 要素 | 定义 | 典型提问 |
|---|---|---|
| 用户 | 执行操作的角色画像 | 谁在使用？有哪些关键特征？（年龄、职业、数字素养） |
| 环境 | 使用发生的物理与社会情境 | 在什么时间、地点使用？网络、光线、噪音如何？ |
| 行为 | 可观测的操作序列 | 用户做了什么？点击、滑动、输入？中途遇到什么？ |
| 目标 | 用户期望达成的最终结果 | 用户为什么这么做？成功标准是什么？ |
采集方法对比
| 方法 | 适合场景 | 单次成本 | 深度 | 样本量 |
|---|---|---|---|---|
| 用户访谈 | 探索早期、复杂决策 | 高 | ★★★★ | 6–10 人 |
| 实地观察 | 操作密集型任务 | 中高 | ★★★★★ | 4–8 人 |
| 日记研究 | 低频/跨周期行为 | 中 | ★★★ | 8–15 人 |
| 问卷调研 | 验证假设、覆盖广 | 低 | ★★ | 50–200 人 |
采集技巧：访谈时多用「具体回忆法」——「请描述最近一次你做 XX 的完整过程，从打开手机开始……」——而非「你通常怎么做？」，前者能获得真实行为细节，后者容易得到用户的美化概括。
场景卡片示例
卡片 ID：SC-2024-008
用户角色：职场白领 · 28 岁 · 通勤距离 12km
使用环境：早高峰地铁 · 人挤人 · 信号断断续续
触发行为：打开手机待办 App，尝试勾选「确认今日待办」
完整操作：解锁 → 打开 App → 列表加载转圈 8 秒 → 失败 → 再试 2 次 → 放弃
目标意图：在到站前完成所有待办确认，到公司直接执行
痛点标注：网络不稳定导致反复加载失败，用户产生焦虑感
2.2 用户故事地图：构建全景需求视图
场景卡片提供了零散的「珍珠」，用户故事地图则用一根线把它们串成完整的用户旅程。地图以横轴表示时间阶段，纵轴表示优先级层级，形成一张全景需求画布，让团队一眼看清「用户从头到尾经历什么」以及「哪些功能必须先做」。
核心结构
| 维度 | 含义 | 对 PRD 的价值 |
|---|---|---|
| 横向 · 用户旅程 | 从开始到结束的完整阶段划分 | 防止遗漏关键环节，确保端到端覆盖 |
| 纵向 · 优先级 | 从上到下：核心功能 → 扩展功能 → 未来优化 | 清晰定义 MVP 边界，指导迭代计划 |
从场景卡片到故事地图：四步映射
- 排序：将所有场景卡片按发生时间顺序排列，识别出 3–5 个关键阶段（如「通勤前→通勤中→到站后」）。
- 写故事：在每个阶段下，用「作为…，我希望…，以便…」格式写出用户故事，一张卡片可拆成多个故事。
- 优先级分层：团队用「不做什么用户就会流失」标准将故事分为 P0/P1/P2，P0 为 MVP 必做。
- 标注边界：在 P0 层画一条切割线，线以上为第一版 PRD 范围，线以下进入 roadmap。
常见误区：不要把用户故事写成「功能描述」。例如「作为用户，我希望离线也能查看待办」是故事；「作为系统，我需要本地缓存数据库」是技术方案。故事聚焦「什么」和「为什么」，不涉及「怎么实现」。
2.3 从痛点出发定义业务问题
场景卡片和故事地图帮我们看清「用户做了什么」，但 PRD 需要回答「我们要解决什么根本问题」。痛点分析就是在场景中定位那些让用户感到挫败、效率低下或不得不放弃的环节，并将它们转化为可验证的业务问题陈述。
痛点三层结构
| 层次 | 定义 | 用户原话示例（通勤场景） | 产品可响应方向 |
|---|---|---|---|
| 表面痛点 | 用户直接说出来的困难 | 「地铁上 app 老是转圈，根本加载不出来」 | 提升网络容错、增加重试机制 |
| 深层痛点 | 行为背后的真实需求 | 「我需要利用碎片时间把事确认完，到公司直接干活」 | 离线确认 + 后台静默同步 |
| 根因痛点 | 导致问题的系统性原因 | 「app 没有离线数据缓存策略，每次都要实时请求」 | 设计本地数据层 + 增量同步协议 |
问题定义公式
将痛点转化为业务问题，建议使用以下结构化公式：
[ 用户角色 ] 在 [ 特定情境 ] 下，因为 [ 痛点 / 困难 ]，需要 [ 解决方案目标 ]，否则会 [ 可衡量的负面影响 ]。
示例（基于通勤场景）：
「职场通勤用户 在 早高峰地铁网络不稳定的环境下，因为 待办应用频繁加载失败导致无法确认今日事项，需要 一套离线可用的轻量确认机制，否则 会导致用户到公司后花费额外 10 分钟补确认，影响晨会效率。」
验证标准：好的问题陈述应当能让两名不同的设计师画出相似的解决方案草图。如果画出来的方案差异过大，说明问题定义还不够精确，需要返回场景卡片补充细节。
2.4 三者协同：从场景到问题的完整链路
场景卡片、用户故事地图与痛点问题定义不是孤立的三个工具，而是一条递进的需求挖掘流水线。下方的流程图展示了从原始用户数据到可验证业务问题的完整演化路径，以及每个阶段的典型输出物。