第2章 用户场景与需求采集方法:用户访谈、数据分析、竞品分析
需求采集是AI产品版本规划的起点。没有高质量的需求输入,版本规划就会变成“猜拳式”的拍脑袋决策。本章围绕三大核心采集方法——用户访谈、数据分析、竞品分析,讲解如何系统化地获取用户场景与业务问题,并将它们转化为版本规划的依据。
2.1 用户场景与业务问题
在采集需求之前,必须先明确两个基础概念:用户场景描述“用户在哪里、遇到什么障碍、期望什么结果”;业务问题则回答“这个场景对产品KPI(留存、转化、活跃)造成了多大的影响”。
案例对照:
用户场景:用户在地下车库打开语音助手,连续三次唤醒失败。
业务问题:弱网/弱信号场景下的唤醒成功率仅为62%,导致次日留存率下降8个百分点。
用户场景:用户在地下车库打开语音助手,连续三次唤醒失败。
业务问题:弱网/弱信号场景下的唤醒成功率仅为62%,导致次日留存率下降8个百分点。
一个合格的采集任务,必须同时输出场景描述和业务问题量化数据,否则后续的版本规划将缺乏优先级决策的依据。
2.2 三大需求采集方法
不同阶段、不同目标应选择不同的采集方法。下表从核心目标、适用阶段、典型产出、样本量和时间成本五个维度进行对比:
| 维度 | 用户访谈 | 数据分析 | 竞品分析 |
|---|---|---|---|
| 核心目标 | 挖掘深层需求与情感动机 | 验证行为假设与使用模式 | 定位差异化机会与行业基线 |
| 适用阶段 | 探索期 / 需求模糊期 | 成长期 / 验证期 | 全周期(尤其规划前) |
| 典型产出 | 用户画像、痛点清单、JTBD | 行为漏斗、功能使用率、留存曲线 | 功能矩阵、Gap分析、SWOT |
| 样本量 | 5 – 15 人 | 全量或大样本(>1000) | 3 – 5 款竞品 |
| 时间成本 | 高(1 – 2 周) | 中(3 – 5 天) | 低(1 – 3 天) |
2.2.1 用户访谈
用户访谈适合在0→1或1→N的探索阶段使用。关键操作要点:
- 采用半结构化提纲:预设6-8个核心问题,留出追问空间。
- 每位用户访谈时长控制在 45 – 60 分钟,超过容易造成疲劳。
- 访谈后 24 小时内完成编码和标签化,避免信息衰减。
- 输出物必须包含原始语录和提炼后的需求陈述两个层次。
避坑提示:不要直接问“你想要什么功能”,用户往往给出方案而非问题。应追问“你现在是怎么做的?那个过程哪里让你最烦躁?”
2.2.2 数据分析
数据分析是用行为事实修正主观判断的关键手段。以AI语音助手产品为例,分析唤醒失败场景的代码示例如下:
import pandas as pd
# 加载用户事件日志
events = pd.read_csv("voice_events.csv")
# 筛选弱网场景下的唤醒事件
weak_net = events[events["network_type"].isin(["2G", "地下停车", "电梯"])]
# 计算各场景唤醒成功率
success_rate = weak_net.groupby("scene")["wake_success"].mean()
print(success_rate)
# 输出示例:
# scene
# 地下停车场 0.62
# 电梯内 0.71
# 楼梯间 0.68
数据分析的关键产出包括:行为漏斗(从触发→唤醒→识别→执行各步流失率)、功能使用热度图(哪些功能被高频/低频使用)、场景渗透率(不同场景下的用户占比和成功率)。
2.2.3 竞品分析
竞品分析不是为了“抄”,而是为了建立差异化的版本规划边界。推荐采用功能矩阵 + 体验基线的双层结构:
- 功能矩阵:列出竞品在相同场景下的功能覆盖度,标记“已有”“缺失”“领先”。
- 体验基线:选取3-5个核心场景,逐一对比成功率、响应时长、错误率等量化指标。
- Gap分析:找出竞品未满足但用户强烈需要的场景,这就是版本规划的“机会窗口”。
2.3 需求拆解与优先级决策
三大方法采集到的原始需求会汇总到需求池。但“用户想要A功能”这样的描述无法直接进入版本规划,必须经过拆解:
- 场景拆解:将需求还原到具体场景,明确触发条件、用户角色、预期结果。
- 问题拆解:量化业务影响(如“唤醒失败率每降低5%,次日留存可提升2%”)。
- 方案拆解:将用户期望转化为技术假设(如“增加离线唤醒模型”)。
优先级决策推荐使用RICE框架(Reach × Impact × Confidence ÷ Effort),每个维度采用1-5分制:
| 需求项 | Reach | Impact | Confidence | Effort | RICE得分 | 优先级 |
|---|---|---|---|---|---|---|
| 地下车库离线唤醒 | 5 | 4 | 4 | 3 | 26.7 | P0 |
| 多语种混合识别 | 2 | 3 | 2 | 5 | 2.4 | P2 |
| 唤醒词自定义 | 3 | 2 | 3 | 2 | 9.0 | P1 |
注意:Confidence ≤ 2 的需求即使得分高也建议先做验证型实验,不要直接放入正式版本规划。
2.4 版本规划方案
优先级排序完成后,将P0需求归入当前版本,P1需求放入下个版本待定,P2及以后进入产品Backlog。每个版本必须包含三类需求:
- 关键场景修复:至少解决1个用户访谈中暴露的高频痛点。
- 数据验证项:包含1-2个可通过A/B测试验证的假设。
- 差异化功能:来自竞品Gap分析中识别出的机会窗口。
2.5 指标验证与验收标准
版本发布后,通过以下标准检验需求采集和拆解的正确性:
| 验收维度 | 指标 | 达标线 | 采集方法溯源 |
|---|---|---|---|
| 场景覆盖率 | 目标场景中需求被满足的比例 | ≥ 90% | 用户访谈 |
| 行为改善 | 核心场景任务完成率提升 | ≥ 15% | 数据分析 |
| 竞争差距 | 与竞品在关键指标上的差距缩小 | ≥ 50% | 竞品分析 |
| 用户满意度 | 版本满意度评分(1-5分) | ≥ 4.0 | 用户访谈 + 问卷 |
最佳实践:在版本规划阶段就为每个P0需求写好验收卡,包含“采集来源→原始需求→拆解后需求→验收指标”的完整链路,这样版本发布后可以直接回溯验证采集方法的有效性。