第3章 用户场景挖掘方法
用户场景挖掘是MVP产品边界划定的第一道工序。团队常常陷入两个极端：要么收集了海量用户故事却无从下手，要么仅凭直觉选定几个功能就匆忙进入开发。本章提供一套可复用的场景挖掘方法，通过场景描述模板结构化记录、用户痛点识别精准定位问题、场景优先级排序聚焦高价值区域，三步递进，将模糊的用户需求转化为可执行的MVP边界输入。
3.1 场景描述模板
场景描述模板是让零散的用户行为变成结构化文档的脚手架。一个完整的场景描述应包含以下七个字段：
| 字段 | 说明 | 填写示例 |
|---|---|---|
| 场景ID | 唯一标识，便于追溯 | SCN-001 |
| 用户角色 | 执行该场景的目标用户身份 | 新注册教师 |
| 场景触发 | 什么条件或事件启动该场景 | 首次登录教务后台 |
| 使用目标 | 用户在该场景下想达成的结果 | 快速创建第一个班级 |
| 行为路径 | 用户完成目标的关键操作步骤 | 登录 → 创建班级 → 填写信息 → 保存 |
| 环境条件 | 使用场景发生的设备、网络与上下文 | PC端 Chrome浏览器，上班时间 |
| 期望结果 | 用户感知的“完成”标准 | 5分钟内创建完毕，收到确认提示 |
模板使用要点：每次用户访谈后，立即用该模板整理2‑3个核心场景。避免事后回忆造成的细节丢失。一个访谈对象至少产出1个完整场景卡。
以下是一个完整场景卡的JSON表达，可用于团队协作工具或需求池：
{
"场景ID": "SCN-001",
"用户角色": "新注册教师",
"场景触发": "首次登录教务后台",
"使用目标": "快速创建第一个班级",
"行为路径": [
"登录系统",
"点击「班级管理」",
"点击「创建班级」",
"填写班级名称与科目",
"点击「保存」"
],
"环境条件": "PC端 Chrome 120 + 校园网",
"期望结果": "5分钟内创建成功，页面提示「班级已创建」",
"痛点候选": [
"找不到创建入口",
"字段过多不知道该填哪些",
"保存后没有成功反馈"
]
}3.2 用户痛点识别
场景卡中的“痛点候选”只是起点。真正的痛点识别需要从四个维度交叉验证，避免将表面抱怨当作真实需求。
| 痛点类型 | 典型描述 | 识别线索（用户原话） |
|---|---|---|
| 效率痛点 | 操作繁琐、步骤过多 | "每次都要……" "太慢了" |
| 体验痛点 | 界面混乱、信息难找 | "找不到……" "藏得太深" |
| 功能痛点 | 缺少关键能力 | "为什么没有……" "要是能……就好了" |
| 认知痛点 | 概念难懂、操作迷茫 | "看不懂……" "不知道下一步做什么" |
避坑提醒：不要将所有用户抱怨都当作痛点。同一个问题如果只出现在1次访谈中，需要继续验证；只有跨用户反复出现的“高频+高影响”问题，才值得进入MVP考虑范围。
痛点识别的四步流程：
- 提取 — 从场景卡的行为路径和用户原话中摘出所有“卡点”；
- 归类 — 按上表的四类痛点进行归类，标注出现频次；
- 评估 — 对每个痛点给出“影响程度（1‑5分）”和“出现频率（1‑5分）”；
- 验证 — 将高分痛点带回给至少3位目标用户做二次确认。
3.3 场景优先级排序
经过模板描述和痛点识别，你会得到一张“场景‑痛点”清单。接下来需要从业务价值、用户影响和实现成本三个维度进行排序，决定哪些场景进入MVP。
| 优先级等级 | 业务价值 | 用户影响 | 实现成本 | 行动建议 |
|---|---|---|---|---|
| P0（必做） | 高 | 高 | 低 / 中 | 纳入MVP核心 |
| P1（应做） | 高 | 中 | 中 | 资源允许时纳入 |
| P2（可选） | 中 | 中 | 中 / 高 | 放到MVP后版本 |
| P3（暂缓） | 低 | 低 | 任意 | 不纳入当前规划 |
排序操作步骤：
- 为每个场景的“业务价值”和“用户影响”打出 1‑5 分（5为最高）；
- 与技术团队估算“实现成本”（人·天），拆分为 低 ≤3天 / 中 4‑8天 / 高 ≥9天；
- 将分数填入优先级矩阵，只有 业务价值 ≥4 且 用户影响 ≥4 的场景才进入 P0 候选；
- 对 P0 候选按成本从低到高排列，MVP 优先选择成本最低的前 3‑5 个场景。
实战经验：一个MVP通常只包含 3‑5 个 P0 场景。超过 5 个场景时，产品边界会变得模糊，开发周期拉长，失去“快速验证”的意义。
团队协作建议：让产品经理、设计师和一名开发共同完成场景挖掘。开发提前介入成本估算，避免P0场景因“技术看起来复杂”被误判为高成本而错失进入MVP的机会。每次场景挖掘工作坊控制在2小时内，输出3‑5张完整场景卡即可。