第3章 用户场景与需求挖掘：场景分类、用户故事地图、痛点识别方法

3.1 为什么场景分类是需求挖掘的起点

任何产品需求都生长在具体的用户场景中。脱离场景的需求要么是伪需求，要么是技术自嗨。场景分类帮助我们系统性地回答三个核心问题：谁在什么情境下为了什么目标使用产品。只有把场景分类做到位，后续的用户访谈、需求拆解、方案验证才有坚实的土壤。

本章从场景分类框架出发，串联用户故事地图、痛点识别、需求拆解、方案表达与验证，形成一条从场景到交付的完整需求挖掘链路。下图展示了这一流程的全貌。

3.2 场景分类三维框架

场景分类不是简单罗列用户“在做什么”，而是从用户角色、行为阶段、使用环境三个维度建立立体分类体系。每个维度对应不同的产品优化视角。

3.3 用户故事地图——从场景到需求的桥梁

用户故事地图将分类后的场景沿着用户旅程横向展开，纵向按优先级分层。它让整个团队在同一张图上看见“用户全流程”和“需求全景”，避免陷入局部功能优化。

构建用户故事地图的核心步骤：

1. 定义用户角色：明确为谁构建地图，例如“注册用户”“企业管理员”。
2. 绘制旅程主干：从左到右列出用户从开始到结束的关键阶段。
3. 填充场景节点：在每个阶段下写出用户的具体行为/动作。
4. 标注痛点和机会：在对应节点下方记录用户痛点、疑问或期望。
5. 按优先级分层：将节点分为“必做”“应做”“可选”，形成发布路线图。

以下是一个生鲜电商APP的用户故事地图模板示例，展示主干结构：

【用户故事地图模板 —— 生鲜电商APP · 注册用户 · 周末居家】
┌─────────────────────────────────────────────────────────────┐
│  打开APP  →  浏览生鲜区  →  选择商品  →  加入购物车  →  结算支付  │
│  ├ 首页加载慢  ├ 分类不清晰   ├ 图片与实物不符 ├ 凑单逻辑混乱 ├ 支付报错   │
│  └ 期望个性化  └ 搜索不好用   └ 缺少用户实拍  └ 运费门槛高  └ 优惠券失效 │
├─────────────────────────────────────────────────────────────┤
│  等待配送  →  收到商品  →  评价反馈                          │
│  ├ 配送时间不准 ├ 包装破损    ├ 评价入口深                    │
│  └ 无实时追踪   └ 缺斤少两    └ 无晒图激励                    │
└─────────────────────────────────────────────────────────────┘

3.4 痛点识别方法

痛点不是用户直接说出来的“我想要XX功能”，而是用户在达成目标过程中遇到的障碍、摩擦、负面情绪。识别痛点需要组合使用以下三种方法：

• 用户访谈法：通过半结构化访谈挖掘用户的具体不便与挫败感。访谈脚本要围绕“最近一次使用经历”展开，避免引导性问题。
• 行为观察法：记录用户操作路径、犹豫点、回退操作、放弃行为。行为比语言更真实。
• 数据分析法：利用漏斗转化率、页面跳出率、功能使用率等指标量化痛点的影响范围。

以下是用户访谈脚本中用于挖掘痛点的核心问题片段：

【用户访谈脚本 · 痛点挖掘节选】
Q1: 请描述您最近一次在APP上购买生鲜的完整过程。
    （追问：当时您是在什么场景下？用手机还是电脑？）
Q2: 在这个过程中，您遇到了哪些让您感到困惑、着急或不方便的地方？
    （追问：具体是哪一步？当时您怎么处理的？）
Q3: 如果让您给这次购物体验打分（1-10分），您打几分？为什么扣分？
Q4: 您有没有因为某个问题而放弃购物或换到其他平台？是什么问题？
Q5: 如果有一个功能可以解决您最头疼的问题，您希望它是什么样子？
    （追问：您愿意为这个功能多花多少时间或额外操作？）

3.5 从痛点到底层需求——需求拆解

每个痛点的背后都隐藏着一个底层需求。需求拆解的任务是穿透用户表面的抱怨，找到功能需求、体验需求、数据需求三个层面的根因。

需求拆解三步法：

1. 归因分析：问“为什么用户会在这个节点感到痛？”——是信息不足？操作太复杂？反馈缺失？还是流程冲突？
2. 分类映射：将归因结果映射到功能（缺什么能力）、体验（交互好不好）、数据（缺什么信息）三个桶中。
3. 优先级排序：按痛点频率 × 痛点强度 × 影响用户数计算优先级得分，确定先解哪个。

3.6 方案表达与指标验证

需求拆解完成后，产品经理需要将需求转化为可执行的方案，并定义验证指标。方案表达遵循“场景→问题→方案→指标”的结构：

• 场景描述：用一句话说清楚用户在什么情境下遇到问题。
• 问题定义：明确当前的痛点及其影响（频率、流失率、客诉量等）。
• 解决方案：提出具体的能力或交互变更，用线框图或流程说明。
• 验证指标：定义1-2个核心指标来度量方案是否成功。

指标验证的常用方法：

3.7 验收标准与交付物模板

需求文档的最终交付物必须包含清晰的验收标准，确保开发、测试、产品三方对“做完了”的定义一致。以下是本章流程对应的验收标准清单和交付物模板。

验收标准清单：

交付物模板：
本章的交付物是一份《用户场景与需求挖掘报告》，包含以下四个部分：

1. 场景分类矩阵（三维标签 + 场景清单）
2. 用户故事地图（旅程主干 + 痛点标注 + 优先级分层）
3. 痛点分析表（痛点描述 → 频率/强度/影响范围 → 底层需求）
4. 需求拆解卡（每个需求对应场景、问题、方案、指标、验收标准）