用户场景挖掘方法：场景地图、用户故事、高频痛点卡片

在AI产品MVP阶段，最危险的错误就是“自以为是”地定义用户需求。本章提供三种互补的场景挖掘工具——场景地图（Scenario Map）、用户故事（User Story）、高频痛点卡片（Pain Point Card），帮助你从模糊的“用户想法”逐步收敛到可验证的MVP需求范围。

3.1 为何要“挖掘”而非“收集”场景？

用户通常只能说出“我想要一个能自动帮我排班的工具”，但无法说出“我需要在周五下午3点前看到下周一的人员缺口”。如果直接收集这样的原始表述，产品会陷入功能堆砌。挖掘的本质是：

• 还原上下文：用户在什么时间、什么环境下产生需求。
• 区分角色：同一个场景下，不同角色的动作和期望截然不同。
• 量化频率与痛度：高频+高痛度 = MVP必须覆盖的场景。

3.2 场景地图（Scenario Map）

场景地图是一种全局视图，横轴是时间或流程阶段，纵轴是参与角色。它帮助你发现“每个人都以为别人会做，结果谁都没做”的盲区。

核心要素

要素	说明	示例（智能客服工单系统）
阶段	用户完成目标所经历的关键步骤	创建工单 → 分配客服 → 处理回复 → 关闭评价
角色	每个阶段涉及的不同人员/系统	客户、一线客服、二线专家、主管
动作	每个角色在该阶段的具体操作	客户提交表单；客服查看历史记录
痛点	动作执行不畅或中断的原因	客服需要登录3个系统查看客户信息

绘制步骤

1. 列出阶段：基于用户访谈和现场观察，整理出从“触发到结束”的5-8个阶段。
2. 添加角色：每个阶段下方列出所有受影响或参与的角色。
3. 填充动作与痛点：用便利贴或数字白板逐格填写，每格不超过15个字。
4. 高亮“断裂点”：将动作中断、信息孤岛、手动操作过多的格子标记为红色。

3.3 用户故事（User Story）

用户故事是场景地图的“缩小镜”，聚焦于一个角色的单一动作，用标准句式描述：
“作为一名<角色>，我希望<动作描述>，以便<价值导向>。”

常见错误拆分

错误类型	反例	正确拆法
包含技术实现	作为客服，我希望API返回工单优先级	作为客服，我希望看到工单的紧急程度，以便优先处理高优先级工单
一次性写太长	作为主管，我希望看到所有工单状态、客服工作量、客户满意度并自动生成报表	拆为3个故事：查看工单状态；查看客服工作量；生成满意度报表
忽略非功能需求	作为客户，我希望能上传图片	作为客户，我希望能上传图片，且上传后5秒内能在页面看到缩略图（非功能约束）

验收条件写法（Gherkin风格）

场景：客服查看工单实时状态
给定 我是一名登录的客服
并且 我的待办工单列表已展开
当 我点击工单编号 “TKT-20250321-001”
那么 系统应在2秒内展示该工单的
  - 当前状态（待处理/处理中/已关闭）
  - 客户方最后留言时间
  - 工单创建后已过时长

3.4 高频痛点卡片（Pain Point Card）

痛点卡片是MVP阶段最终判断“做不做”的关键依据。它记录了场景地图中标记的每个痛点，并按频率和痛度排序。

卡片模板

字段	内容示例
痛点编号	PP-07
场景出处	场景地图：工单分配阶段
角色	一线客服
痛点描述	每次接手新工单，需要手动从3个系统复制客户信息
频率	每天 20-30 次
痛度（1-5）	5（导致平均耗时超15分钟）
关联用户故事	US-103：查看客户历史摘要

排序与优先级

将痛点卡片按 频率 × 痛度 排序，得分最高的前3-5张卡片对应的用户故事，即为MVP必须实现的内容。

3.5 三种工具的关系

下面这张流程图展示了从用户访谈产出到MVP需求范围的完整链路，以及场景地图、用户故事、痛点卡片在其中的位置与协作关系。

3.6 本章交付物模板

完成本章学习后，请输出以下交付物：

• 一张场景地图：至少包含4个阶段、3个角色、10个痛点标注。
• 至少10个用户故事：覆盖场景地图中高亮断裂点对应的动作。
• 一套高频痛点卡片：每个痛点独立卡片，包含频率、痛度、关联用户故事。
• 优先级排序列表：按频率×痛度排列，标明MVP第一轮实现的前3项。