用户研究
用户研究
一、工程案例:查清「新用户 7 日留存下滑」的真实原因
下面用一套示例数据把流程走完。数字是示例,可直接复用的是步骤、判断口径和验收标准。
场景:一款团队协作工具,注册后 7 日留存从 31% 降到 22%。团队已经得出判断:「引导流程太长,用户没耐心。」两周后准备重做 onboarding。
约束:
| 约束 | 具体内容 |
|---|---|
| 时间 | 2 周内给出结论,赶在改版排期之前 |
| 人力 | 1 名研究员兼产品,没有专职数据分析师 |
| 技术 | 埋点已冻结,本迭代不能加新事件 |
| 预算 | 访谈礼金 14 份,问卷无付费样本渠道 |
| 目标 | 判断「重做引导」是否是对的方向,并给出可执行的改动清单 |
推进顺序:
起手动作:先把「重做引导」这个方案放一边,写一张决策问题卡。
1.1 决策问题卡
决策:下个迭代是否把全部研发投入重做 onboarding?
如果结论是「引导长度不是主因」→ 取消重做,改为修复具体断点。
如果结论是「确实是引导问题」→ 按访谈发现重排步骤。
如果两周内无法判断 → 先做最小改动,再观察一个周期。这张卡的作用:提前约定「什么结论会导致什么动作」。写不出这一行,研究就会变成找证据支持既有方案。
1.2 先用现有埋点拉漏斗
不加新事件,只用已有事件重算:
| 步骤 | 转化率 | 与上季度对比 |
|---|---|---|
| 注册 → 创建第一个项目 | 78% | 持平 |
| 创建第一个项目 → 次日回访 | 62% | 下降 9 个百分点 |
| 次日回访 → 7 日留存 | 45% | 下降 11 个百分点 |
| 注册 → 7 日留存(整体) | 22% | 下降 9 个百分点 |
再按「建项目后 24 小时内是否邀请」分组:
| 分组 | 占比 | 7 日留存 |
|---|---|---|
| 建项目后 24 小时内邀请 | 31% | 71% |
| 未邀请 | 69% | 18% |
读法:注册到建项目的转化没变,说明引导步骤数不是主要变量;分化出现在建项目之后,邀请组的 7 日留存约为未邀请组的 4 倍。三步转化率相乘约 22%,与整体对得上,说明口径一致。
但不能直接说「邀请导致留存」:也可能是本来就活跃的人才会邀请。因果方向要靠访谈判断,数据只负责指出「哪里不一样」。
1.3 定样本结构
不按「找 10 个人聊聊」招募,按行为分层:
| 分层 | 条件 | 目标人数 | 作用 |
|---|---|---|---|
| 流失新用户 | 注册 7 天内未回访 | 6 | 听未说出口的阻力 |
| 留存新用户 | 注册 7 天内回访 3 次以上 | 4 | 找可复制的路径 |
| 老用户 | 使用超过 6 个月 | 2 | 对照流程变化 |
| 被拒用户 | 注册后未建项目 | 2 | 看更早的断点 |
样本量说明:定性研究看的是「是否出现新信息」,不是统计代表性。上述 14 人里,若连续 3–4 位新受访者不再带来新标签,即可停止。
1.4 招募筛选问卷(5 题)
1. 你注册这个产品多久了?(单选)
2. 过去 7 天,你打开过几次?(单选:0 / 1–2 / 3 次以上)
3. 你最近一次用它做了什么?(开放)
4. 你的团队有多少人?(单选)
5. 是否愿意接受 30 分钟电话访谈?(留联系方式)筛选的两个作用:按第 2 题分层,按第 5 题控制意愿偏差。愿意接受访谈的人,通常本身就偏活跃,所以流失组要多招,必要时用站内信定向邀请。
1.5 访谈提纲:只问过去
开场:今天不推销,也不问建议,只想听你上次实际怎么用的。
1. 注册那天,你本来想解决什么事?
2. 从注册到第一次用起来,你按顺序点了哪些地方?
3. 有没有哪一步停下来过?当时屏幕上是什么?
4. 关于邀请同事,你当时怎么想的?后来邀请了吗?
5. 如果那天没做成,你改用了什么?
6. 后来为什么没有再打开?追问句式:「然后呢」「当时你看到了什么」「你点了哪里」。不问「你觉得」「你希望」,除非已经问完行为。
1.6 访谈记录与编码
访谈当天整理,把原话切成短句,贴标签,统计出现在几个人的记录里:
| 原话 | 标签 | 出现人数 |
|---|---|---|
| 「我自己先试试,不想拉同事进来」 | 独自觉察价值 | 5/6 流失 |
| 「不知道邀请他们来干嘛」 | 邀请价值不明 | 4/6 流失 |
| 「等我想好怎么用再拉人」 | 时机过早 | 3/6 流失 |
| 「模板挺有用,直接改就行」 | 模板降低启动成本 | 3/4 留存 |
| 「同事发了链接给我,我就进来了」 | 被动加入路径 | 3/4 留存 |
编码的价值:把「某个用户说过」变成「几个人说过」。前者是个案,后者才可能是一条模式。
边界:人数少时不谈比例,只写「6 人中有 5 人」。样本小却写百分比,会让结论显得比实际更确定。
1.7 用问卷验证规模
访谈给出假设,问卷验证普遍性。用现有用户列表发站内信,回收 186 份:
| 题目 | 结果 | 对应假设 |
|---|---|---|
| 注册后你是否知道「邀请同事」能做什么 | 62% 选「不清楚」 | 邀请价值不明 |
| 你更希望先自己试用,还是先拉同事 | 71% 选「先自己」 | 独自觉察价值 |
| 你第一次使用时有可参考的模板吗 | 38% 选「没有」 | 模板缺口 |
| 你现在还在使用吗 | 44% 选「是」 | 样本偏活跃,需与总体对照 |
问卷的局限:发的是现有用户,天然偏向留存者,实际比例以回收数据为准。结论里必须写明这一偏差,不能把答卷里的比例当成整体留存率。
1.8 关键产出物:一页结论
结论一:分化发生在建项目之后,不在注册流程长度。
证据:注册到建项目持平;未邀请组 7 日留存 18%,邀请组 71%;
6 名流失用户中 5 人提到「想先自己试」。
结论二:邀请被设计成必经步骤,但用户尚未理解其价值。
证据:62% 问卷受访者不清楚邀请能做什么;4 人提到「不知道拉人干嘛」。
结论三:模板与首次启动顺畅相关,值得优先验证。
证据:4 名留存用户中 3 人从模板开始;38% 的问卷受访者说首次使用时没有可参考模板。
说明:相关不等于因果,模板的作用要用灰度对比确认。写法要求:每条结论下面必须有证据,证据要能指回原话或数据。没有证据的结论,放在「待验证」区,不放进结论页。
1.9 改动清单与灰度
| 改动 | 依据 | 工作量 | 验证指标 |
|---|---|---|---|
| 邀请改为可选 | 结论一 | 小 | 未邀请用户的 7 日留存 |
| 延后邀请提示到创建第 3 个任务后 | 结论二 | 小 | 邀请率、7 日留存 |
| 提示语写清「邀请后能一起做什么」 | 结论二 | 小 | 提示点击率 |
| 新用户默认进入模板库 | 结论三(待验证) | 中 | 首个任务创建率 |
决策:取消原定的 onboarding 重做,只做上表四项。省下的排期用于修复邀请流程的权限报错。
1.10 验收(6 项全过才算完成)
| 检查项 | 怎么验 | 通过标准 |
|---|---|---|
| 邀请可选 | 新注册账号不邀请任何人 | 能直接进入工作区并创建任务 |
| 延后提示 | 连续创建 3 个任务 | 第 3 个任务后出现一次提示,不重复弹出 |
| 提示文案 | 读一遍提示语 | 写明邀请后能做什么,不出现「立即邀请」这类空话 |
| 模板入口 | 新账号首次进入 | 默认展示模板列表,可跳过 |
| 指标回升 | 灰度 2 周后对比同期 | 7 日留存不低于 28%(基线 22%),邀请率不下降 |
| 无副作用 | 查客服工单与崩溃日志 | 无新增权限类工单,无报错上升 |
第 5 项设了下限而不是目标值:留存受季节与渠道影响,单看一个数字容易误判。阈值按基线 22% 定,灰度结论以实际回收数据为准。同时看邀请率,是为了防止「不强制」变成「没人邀请」。
1.11 结果与回访
灰度满 4 周复核,7 日留存稳定在 34%,邀请率从 31% 升到 52%,首个任务创建率从 41% 升到 58%。第 6 周做 5 次回访,重点问「提示出现时你在做什么」,据此又把提示从弹窗改成行内提示。
这个案例的要点:团队的猜测是「引导太长」,数据指向的是「过早强制社交」。如果直接重做 onboarding,会花掉两周并且不解决问题。研究的价值不是证明谁对,而是在投入之前把方向调正。
二、高频问答:会卡住你的地方,也是面试最常问的
2.1 访谈中用户全程说「挺好的」
现场
换问具体事件:「上一次用是什么时候,点了哪几步,哪里停过?」;再让对方共享屏幕演示一遍。
要点
- 「挺好」是态度层回答,信息量为零。
- 现场有录音或旁听时,用户倾向给面子,不会主动说负面。
- 说不出具体时间和步骤的「挺好」,等于没问。
追问
- 用户还是只说好话呢?→ 让他演示,卡住的地方会自己出现。
- 怎么问才不问到态度?→ 问过去的行为和当时看到的界面,不问「你觉得」。
- 演示很流畅就没问题吗?→ 先看是不是熟练用户,新手路径才是主要风险。
2.2 用户说的和做的不一致
现场
用埋点或现场观察对照;问「上次具体怎么做的」,不问「你一般怎么做」。
要点
- 人描述的是「应该怎么做」的自我形象,行为发生在具体约束下。
- 不一致不是品德问题,两者都真实,只是回答的是不同问题。
- 以行为为主,以说法解释动机。
追问
- 数据说一套、访谈说另一套,信哪个?→ 数据看分布,访谈看原因,先确认两边口径一致。
- 用户记错了怎么办?→ 用历史记录、截图、工单对齐,不靠回忆。
- 观察也会改变行为呢?→ 有霍桑效应,安排适应期或改用日记法。
2.3 老板已经定了方案,让研究去「验证」
现场
先写决策问题卡:「如果结论相反,方案会改吗?」答案是否,就改为「验证风险」而不是「验证正确」。
要点
- 研究被当成背书工具时,决策问题其实没有开放。
- 配合演出会让团队在错误方向上更自信,也会让研究失去价值。
- 提前约定「什么证据会改变决定」,并把相反证据单独列一节。
追问
- 老板不接受反向结论怎么办?→ 把风险和代价写进结论,决策权仍在对方。
- 还能做什么?→ 至少验证最大风险点,别把预算花在复述已知。
- 怎么写才不像对抗?→ 用「如果……则……」的决策卡,谈条件不谈立场。
2.4 访谈 5 个人,结论互相矛盾
现场
按行为或角色给受访者分组,看矛盾是否沿分组边界出现。
要点
- 用户处在不同阶段、不同角色,矛盾本身就是分层信号。
- 矛盾往往指向两个不同的需求,而不是数据错误。
- 「挑典型」会抹掉差异,也会让结论显得比实际确定。
追问
- 分组之后每组只有一两个人呢?→ 只写个案,不谈比例。
- 矛盾沿不出分组边界呢?→ 说明提纲没覆盖关键变量,补一轮。
- 要不要取平均?→ 不要,两个方向的需求分别立项比折中更有效。
2.5 问卷回收率很低
现场
查发放渠道的打开率与点击率;用小范围 A/B 测标题与题量。
要点
- 回收率低先看漏斗:没看到、看到没点、点了没答完,三段原因不同。
- 渠道不对、题目太多、没说明用途与耗时,是三个常见原因。
- 先修触达,再修题目。
追问
- 样本量不够能出结论吗?→ 只看方向,不谈比例,并写进局限。
- 只发站内信可以吗?→ 只能覆盖活跃用户,流失用户要走短信或邮件。
- 题目多少合适?→ 手机端通常控制在 5 分钟内,约 10–12 题。
2.6 招募来的全是活跃用户
现场
查样本的来源分布;对比总体用户的活跃分布,看偏差有多大。
要点
- 招募渠道只覆盖了站内信和社群,流失用户已经不在这些渠道里。
- 「容易招到」不等于「有代表性」。
- 只在留下来的用户里做研究,结论天然偏向产品已经做对的部分。
追问
- 流失用户怎么招?→ 走短信、邮件、客服回访名单,用独立渠道。
- 补几个够?→ 按分层定,不按总数定,流失组要多招。
- 意愿偏差怎么处理?→ 招募时写明条件:需要经历过某场景的人。
2.7 用户说「有这个功能我会用」
现场
改问「现在这件事你怎么解决的、花了多久」;有条件就做可点击原型,看真实操作。
要点
- 假设性提问会激发配合心理,口头使用意愿通常被高估。
- 看用户是否已经在为这件事付出成本:时间、钱、替代工具。
- 没有现成替代方案的「会用」,多数不会发生。
追问
- 原型测试也会失真吗?→ 会,但比口头强,看操作卡点而不是看评价。
- 用户现在就手工做着呢?→ 那才是真需求,问清频次和代价。
- 怎么验证付费意愿?→ 看这笔开销从哪个科目出,别问「愿不愿意付」。
2.8 研究结论没人采纳
现场
回看报告:有没有明确结论、有没有建议做与不做、有没有对应指标。
要点
- 报告写成过程记录,没有对应到具体的排期与取舍,就无法被采纳。
- 一份没有取舍建议的报告,本来就无法执行。
- 结论要落到「谁在什么时间做什么」。
追问
- 是不是团队只信老板?→ 先排除报告本身不可执行,再谈政治。
- 结论和排期冲突怎么办?→ 给出「做 / 不做 / 先验证」三档建议。
- 怎么提高采纳率?→ 让决策者在研究开始前就参与决策问题卡。
2.9 访谈对象是熟人,不好意思说真话
现场
查访谈记录里有没有具体的失败经历;没有,就换第三方访谈或改为观察。
要点
- 熟人会顾及关系,跳过负面评价,也会顺着你的期待回答。
- 「好约」不等于「样本合适」。
- 全是认同的访谈,通常不是样本好,是关系太近。
追问
- 熟人访谈完全不能用吗?→ 可以用来摸流程,不能用来判断满意度。
- 怎么让熟人放松又敢说?→ 不问评价,只让他演示操作。
- 第三方访谈成本高怎么办?→ 让同事代访,或改成现场观察。
2.10 访谈变成需求收集会
现场
统计访谈里「方案类发言」与「行为类发言」的比例;前者明显偏多,就说明提纲偏了。
要点
- 提问重心落在「你想要什么」,用户自然开始点菜。
- 用户不是产品经理,建议只能当线索。
- 建议记录为「用户设想的解法」,单独存放,不直接进排期。
追问
- 用户提的建议很好呢?→ 记下来,但仍要回到行为和代价验证。
- 怎么把话题拉回来?→ 用「上一次你当时怎么做的」把对方带回场景。
- 访谈里能不能顺便收集需求?→ 可以收原话,不要当场承诺排期。
2.11 有人质疑「才 8 个人,能代表什么」
现场
说明样本结构与目的;再用问卷或数据验证该结论的普遍性。
要点
- 定性与定量的目标不同:定性找模式与假设,定量验证规模。
- 小样本不能证明比例,但能发现你没想到的问题。
- 用统计代表性质疑探索性研究,是拿错了尺子。
追问
- 8 个人够吗?→ 看是否饱和,连续 3–4 位不再带来新标签即可停。
- 怎么让质疑的人服?→ 叠一层问卷或埋点,给出比例。
- 分层之后人更少呢?→ 每层写个案,不写百分比。
2.12 研究做完,不知道要改什么
现场
翻决策问题卡;没有就现在补一行:「这次研究要支持哪个决定」。
要点
- 立项时没写决策问题,结论自然落不到动作上。
- 用更多信息掩盖目标缺失,是研究最常见的浪费。
- 要从决策倒推需要的信息,而不是从信息堆里找结论。
追问
- 探索性研究也要先定决策吗?→ 可以不定,但要说明「不承诺结论直接进排期」。
- 结论有了但改什么不清楚?→ 每条结论配一条建议动作和验证指标。
- 要不要再补一轮访谈?→ 先看缺的是信息还是决策,缺决策补访谈没用。
2.13 录音、截图和用户原话直接发进了大群
现场
招募时写明用途、保存期限与撤回方式;分享前脱敏,去掉姓名、公司与账号;只发结论和必要片段。
要点
- 录音、截图、联系方式属于个人信息,未经同意扩散,轻则失去用户信任,重则触碰合规要求。
- 「内部」不等于「可以随便传」。
- 资料的安全边界要在收集之前定,不是出事之后补。
追问
- 已经发出去了怎么办?→ 撤回、记录扩散范围,按内部流程报备。
- 只发原话不发姓名可以吗?→ 仍可能被认出来,引语要改写或合并。
- 研究资料要存多久?→ 按招募时承诺的期限删,不要无限期留着。
三、核心知识:从零开始要建立的东西
3.1 研究问题与决策问题
| 类型 | 例子 | 产出 |
|---|---|---|
| 决策问题 | 下个迭代要不要重做引导 | 做或不做的判断 |
| 研究问题 | 新用户在哪些步骤停止 | 断点与原因 |
| 访谈问题 | 上一次使用时你点了哪些地方 | 具体行为 |
三者的顺序是从上到下:先有决策,再定研究问题,最后写访谈问题。反过来做,会收集一堆有趣但无法支撑决策的材料。
判断标准:一个研究问题如果无论答案是什么都不改变行动,就不该问。
边界:探索性研究允许先收集再定问题,但要在开始时就说明「这次是探索,不承诺结论直接进排期」。
3.2 定性与定量的分工
| 定性 | 定量 | |
|---|---|---|
| 回答 | 为什么、如何发生 | 有多少、多普遍 |
| 样本 | 8–15 人 | 数百到全量 |
| 输出 | 假设、机制、原话 | 比例、趋势、分组差异 |
| 风险 | 不能代表整体 | 不能解释原因 |
常见顺序:定性找假设,定量验规模。反过来也成立——先在数据里看到异常,再回访找原因,但必须回到人身上确认。
边界:定量能告诉你「有多少人卡在这一步」,不能告诉你「他们为什么卡」。定性反之。两者都不能单独支撑一个高成本决策。
面试:常问「才访谈了 8 个人,结论可信吗?」答:定性找假设和机制,定量验规模,小样本能发现你没想到的问题,但不能证明比例。
3.3 访谈结构的三类
| 结构 | 特点 | 适合 | 风险 |
|---|---|---|---|
| 结构化 | 固定问题、固定顺序 | 多人横向对比 | 追问不足 |
| 半结构化 | 有提纲,可追问 | 多数产品访谈 | 依赖访谈者水平 |
| 非结构化 | 自由聊 | 陌生领域探索 | 难以横向比较 |
半结构化的实操:提纲写 6–8 个问题,每个问题下准备 2 个追问句。问题负责覆盖,追问负责深度。
边界:跨地区、跨角色的对比研究用结构化;早期探索用非结构化。半结构化是默认选项,不是唯一选项。
3.4 过去行为的提问方式
| 想问的 | 不要问 | 改问 |
|---|---|---|
| 使用频率 | 你平时常用吗 | 上次用是哪天,做了什么 |
| 痛点 | 你觉得哪里不好用 | 上一次卡住是哪一步,屏幕上是什么 |
| 替代方案 | 你还用过别的吗 | 这件事在没用我们之前怎么做的 |
| 付费意愿 | 你愿意付多少钱 | 现在这笔开销从哪个科目出 |
| 决策链 | 你们谁说了算 | 上次采购是谁签的字,走了哪些流程 |
「上一次」通常是最有效的问法:它把用户从想象中的自己拉回具体场景,细节会自动出现。
边界:低频行为(一年一次)用「上一次」会失真,改用日记法或调取历史记录。
3.5 引导性提问的识别
| 类型 | 例子 | 问题 |
|---|---|---|
| 预设结论 | 你是不是觉得这个很难用 | 用户会顺着点头 |
| 假设未来 | 如果有这个功能你会用吗 | 高估使用意愿 |
| 二元选择 | 你喜欢 A 还是 B | 丢掉「都不喜欢」与原因 |
| 双重问题 | 是不是又快又好用 | 两个维度混在一起 |
自查方法:把问题读给没参与项目的同事听,问「这个问题希望我答什么」。能听出期待答案的,就是引导性问题。
边界:追问时难免带一点倾向,关键是不要把倾向写进结论。问题可以有温度,结论必须有证据。
3.6 情境观察与日记法
| 方法 | 做法 | 适合 | 成本 |
|---|---|---|---|
| 情境访谈 | 到用户工作现场,边做边问 | 流程复杂、桌面软件 | 高,需出差 |
| 影子观察 | 跟一整天,只记录不打断 | 发现未意识到的步骤 | 很高 |
| 日记法 | 连续记录 1–2 周 | 低频、跨场景行为 | 中,依赖用户配合 |
观察能发现「说不出来」的东西:
用户说:用 Excel 管库存挺方便的
现场看到:开了 6 个表来回切,贴了便签提醒自己核对
真实问题:数据分散,靠人肉记忆防错边界:观察会被「被看着」影响(霍桑效应),用户通常表现得更规范。安排一段适应期,或改用日记法降低干扰。
3.7 问卷的题型与量表
| 题型 | 用途 | 注意 |
|---|---|---|
| 单选 | 分类、分层 | 选项互斥且穷尽 |
| 多选 | 场景、工具组合 | 限制可选数量,避免全选 |
| 李克特量表 | 满意度、认同度 | 5 级或 7 级;是否保留中间态按研究目的定 |
| 排序 | 优先级 | 选项通常不超过 6 个 |
| 开放题 | 补充原因 | 放最后,最多 2 题 |
量表的方向要一致:同一份问卷里不要一半「1 表示满意」、一半「1 表示不满意」。
长度控制:手机端通常控制在 5 分钟内,约 10–12 题;超过这个长度,完成率通常下降,具体以实际回收数据为准。
边界:问卷不适合探索未知原因,开放题的回答率通常很低,不能作为主要证据来源。
3.8 样本结构与饱和
| 研究类型 | 常见样本量 | 说明 |
|---|---|---|
| 可用性测试 | 5–8 人/轮 | 常用经验值,具体看问题类型与用户分层 |
| 深度访谈 | 8–15 人 | 以不再出现新标签为准 |
| 情境观察 | 3–5 人 | 耗时长,重深度 |
| 问卷 | 通常上百份起 | 看总体规模与分层 |
饱和的判断:连续若干次(常见经验为 3 次左右)访谈没有出现新标签,且原有标签都有多人支持,可考虑停止;是否饱和以研究问题和分层为准。
样本结构比数量重要:按行为分层抽样,让新用户、老用户、流失用户各占一部分,才能看到完整图景。
边界:面向专家或极端用户的研究,饱和来得更慢,需要预留更多样本。
面试:常问「访谈做到多少人可以停?」答:看饱和,连续 3 次左右不再出现新标签、且各分层都有人支持,就可以停。
3.9 招募渠道与激励偏差
| 渠道 | 偏向 | 适用 |
|---|---|---|
| 站内信 | 活跃用户 | 留存研究 |
| 短信、邮件 | 流失用户 | 流失原因 |
| 客服工单 | 遇到问题的人 | 故障与体验 |
| 社群 | 高投入用户 | 深度共创 |
| 付费样本库 | 职业受访者 | 快速但需筛重 |
激励的设计:礼金适中即可,过高会吸引为钱而来的人。招募时说明「我们需要经历过某场景的人」,比「找 10 个人聊聊」有效。
边界:B 端研究常需通过客户对接人招募,对接人会挑「关系好」的用户,必须要求按条件名单抽取,而不是让对接人自由推荐。
3.10 用户画像的决策用途
| 要素 | 写什么 | 能支撑的决策 |
|---|---|---|
| 角色与职责 | 在组织里负责什么 | 功能给谁用 |
| 目标 | 要达成什么结果 | 价值主张 |
| 痛点 | 现在什么最耗时间 | 优先级 |
| 行为特征 | 用什么工具、什么习惯 | 交互方式 |
| 决策影响力 | 能不能拍板、影响谁 | 销售与定价 |
画像的检验标准:每一条信息都要能回答「所以设计上要做什么」。答不上来的删掉。
反画像:明确「不服务谁」,能挡住一部分功能蔓延。例如「不为 3 人以下团队做审批流」。
边界:画像通常控制在 4 个以内,多了团队记不住;优先按角色与行为分,人口属性只作辅助。
面试:常问「用户画像除了贴标签还有什么用?」答:每条信息都要能回答「所以设计上要做什么」,答不上来的就删掉。
3.11 旅程地图的四个层次
| 层 | 内容 | 证据来源 |
|---|---|---|
| 阶段 | 用户经历的主要步骤 | 访谈、观察 |
| 行为 | 每步做了什么 | 观察、埋点 |
| 触点 | 通过什么渠道或界面 | 产品、客服、邮件 |
| 情绪 | 每步的感受与波动 | 访谈原话、表情与停顿 |
地图的价值在暴露非界面问题:用户可能在「听说」阶段就流失(渠道问题),也可能在「付款」阶段卡住(合同问题),这些都不在界面里。
边界:旅程地图是定性工具,不能标百分比。要标比例,需叠加埋点或问卷数据。
3.12 JTBD 的三重任务
| 维度 | 问题 | 例子(买钻头) |
|---|---|---|
| 功能任务 | 要完成什么 | 在墙上挂一幅画 |
| 情感任务 | 想感觉如何 | 不想把墙打坏,想一次成功 |
| 社会任务 | 想被如何看待 | 显得会干活、有条理 |
JTBD 的用途:把注意力从「竞品有什么功能」转到「用户在完成什么任务」,从而看到跨品类替代方案(免钉挂钩、胶条、找人帮忙)。
边界:JTBD 适合解释「为什么换」,不适合直接推导功能清单。它给出的是问题空间,不是方案。
3.13 可用性测试的边界
| 用户研究 | 可用性测试 | |
|---|---|---|
| 问题 | 要不要做、为谁做 | 这个设计能不能用 |
| 时机 | 概念与规划 | 设计稿或可点击原型 |
| 输出 | 需求与假设 | 可用性问题清单 |
| 样本 | 目标用户,按行为分层 | 目标用户,按任务熟练度分层 |
两者不能互相替代:可用性测试做得再好,也发现不了「用户根本不需要这个功能」。
边界:可用性测试要给出具体任务与成功标准,例如「找到上个月的订单并退款」,而不是「随便看看」;主持人只复述任务,不提示路径。
3.14 研究结论的组织方式
1. 结论:通常三条,每条一句话
2. 证据:原话、数据、出现人数
3. 建议:做什么、不做什么、先后顺序
4. 方法:样本、时间、渠道
5. 局限:偏差、未覆盖人群、待验证项最有说服力的是原话加计数:
✘ 用户对筛选功能不满意
✔ 6 位用户中 4 位在筛选后说「怎么没变化」,
其中 1 位重复点了 3 次后放弃主动写局限:样本偏活跃、只覆盖一个行业、访谈在版本更新前完成。承认局限不会削弱结论,反而让结论更可信。
边界:报告通常控制在两页内。详细记录放附录,会上只讲结论与建议。
四、冷门知识汇总
高频卡点在第二节,常用基础在第三节;这一节只收低频、出错代价低、用到时能现查的内容。
| 知识点 | 为什么冷门 | 用到时的关键词 |
|---|---|---|
| 日记法 | 执行周期长,多数项目等不及 | 连续记录一周、低频行为 |
| 影子观察 | 成本高,只在流程复杂的项目里用 | 跟访一整天、不打断 |
| 情境访谈 | 需要到现场,远程项目很少做 | 工作现场、边做边问 |
| 反画像 | 正向画像还没用好,很少做到排除 | 不服务谁、功能蔓延 |
| 饱和度 | 定性研究的收尾判断,报告里很少写 | 不再出现新标签 |
| 职业受访者 | 付费样本库的副作用 | 筛重、激励过高 |
| 社会赞许偏差 | 学术名称,日常只说「给面子」 | 正面回答、旁听影响 |
| 霍桑效应 | 被观察时行为改变 | 适应期、非侵入观察 |
| 情绪曲线 | 旅程地图的附属产物 | 高点、低点、触点 |
| JTBD 的三重任务 | 概念流行,实际很少完整使用 | 功能、情感、社会任务 |
| 访谈录音的转写 | 耗时长,常被跳过 | 逐字稿、时间戳 |
| 卡片分类 | 只在信息架构改版时用 | 开放式卡片、闭集排序、相似度矩阵 |
| 认知走查 | 专家评审法,不必招用户 | 新手视角、逐步走查、四问清单 |