研究计划的价值，不是让文档显得完整，而是让团队在开始招募之前就回答清楚：这次研究要影响哪一个决定，什么证据才算够，谁会用到结论。方法、人数和排期都应该服从这个决定。
研究计划的价值，不是让文档显得完整，而是让团队在开始招募之前就回答清楚：这次研究要影响哪一个决定，什么证据才算够，谁会用到结论。方法、人数和排期都应该服从这个决定。
01 先给结论：一页纸也能成为好计划
很多团队写用户研究计划时，第一行就开始列“访谈、问卷、可用性测试”。看起来很专业，真正执行时却会发现三个问题：访谈对象不知道该找谁，问题越问越散，报告做完也没人知道该改什么。
更实用的写法是先把计划压缩成八个决策：为什么研究、要回答什么、研究谁、怎么找人、用什么方法、何时完成、交付什么、哪些结论不能下。 如果这八项说不清楚，文档再长也只是活动清单。
02 把业务问题翻译成研究问题
业务问题通常带着目标，研究问题则要能通过观察或对话获得证据。两者不能直接画等号。
| 业务方原话 | 不够好的研究问题 | 更可执行的研究问题 |
|---|---|---|
| 新用户为什么不下单？ | 用户喜欢新版首页吗？ | 用户在第一次浏览时如何判断产品是否适合自己？在哪一步停止继续了解？ |
| 审批系统使用率低 | 用户为什么不愿意用？ | 不同角色如何发起、查找和处理审批？哪些线下动作仍然不可替代？ |
| 想增加高级套餐转化 | 用户愿不愿意多付钱？ | 用户如何理解套餐差异？哪些能力被认为必须包含，哪些只在特定情境下有价值？ |
写研究问题时，尽量使用“如何判断、如何完成、在哪一步、基于什么信息”这类表达。少用“是否喜欢、是否满意、会不会购买”。后者容易把研究变成态度调查，得到礼貌但无法行动的答案。
03 研究计划的八个核心部分
1. 决策背景
用三到五句话说明现在发生了什么，以及团队准备作出什么决定。不要把项目介绍复制一遍。一个合格的背景应该包含当前证据，例如转化漏斗、客服问题、销售反馈、历史研究或已知风险。
2. 研究目标
目标不是“了解用户需求”，而是说明研究完成后要支持什么决定。例如：确认新版导航是否可以进入开发；决定首批功能范围；验证企业管理员与普通成员是否需要不同入口。
3. 研究问题
建议控制在三到六个。问题过多通常意味着目标没有收紧。每个研究问题都应能对应一种证据：用户行为、原话、任务结果、现有数据或工作现场。
4. 参与者条件
不要只写“5名用户”。至少写清角色、经验、使用频率、业务规模、设备或工作环境，以及必须排除的人群。
| 维度 | 示例条件 | 为什么重要 |
|---|---|---|
| 角色 | 发起人、审批人、流程管理员 | 同一流程里的目标和权限不同 |
| 使用频率 | 每周处理10次以上 / 每月偶尔使用 | 熟练用户与低频用户的困难不同 |
| 经验 | 新手、迁移用户、长期用户 | 影响对概念和旧习惯的理解 |
| 场景 | 办公室、移动途中、现场作业 | 决定设备、网络与时间压力 |
5. 方法与材料
先选证据，再选方法。想知道工作如何发生，优先做现场观察或情境访谈；想验证任务是否能完成，使用可点击原型做可用性测试；想理解大范围分布，再考虑问卷和日志数据。
6. 招募与合规
写明招募渠道、筛选问卷、激励、知情同意、录音录像方式，以及敏感信息如何处理。B端研究还要提前确认客户经理是否需要陪同，以及陪同是否会影响参与者表达。
7. 排期与责任
研究不是“周一开始，周五交报告”这么简单。至少拆分为准备、招募、试测、正式研究、快速同步、综合分析和结论评审。
8. 输出与边界
提前约定交付的是机会地图、问题清单、原型修改建议、关键片段，还是决策备忘录。同时写出本轮不能回答什么。明确边界比事后解释“样本不够”更有价值。
04 方法怎么选：先看问题，不看团队习惯
| 想回答的问题 | 更合适的方法 | 不适合单独依赖的方式 |
|---|---|---|
| 用户实际怎样完成工作 | 情境访谈、现场观察、日志分析 | 只在会议室里问“平时怎么做” |
| 新流程能否顺利完成 | 原型可用性测试、任务走查 | 只做设计评审 |
| 概念和价值主张是否理解 | 概念测试、深度访谈 | 直接问“你会买吗” |
| 问题在多大范围存在 | 行为数据、问卷、客服工单统计 | 只用少量访谈推算比例 |
| 两个方案哪个表现更好 | 明确指标的对比测试或实验 | 凭团队投票 |
方法不必追求多。一次研究最常见的失败不是方法太少，而是每种方法都做一点，最后没有一类证据足以支持决定。
05 样本怎么定：覆盖差异比追求整数更重要
小规模访谈和可用性测试经常以一轮4至8人开始，但这不是所有项目的固定公式。真正要看的是参与者之间是否存在会改变行为的差异。
以B端审批系统为例，如果本轮同时研究发起人、一级审批人和流程管理员，招募6人并不代表每类角色都被充分覆盖。更稳妥的做法是建立“样本矩阵”：把必须覆盖的角色放在行，把经验、企业规模或使用频率放在列，确保关键组合没有空白。
当连续几场研究不再出现新的关键问题，可以结束这一轮；当某个关键角色的行为明显不同，应追加，而不是为了凑满预设人数继续招同一种用户。
06 两种常用排期
五个工作日的快速验证
| 时间 | 工作 |
|---|---|
| 第1天 | 对齐决策、研究问题和参与者条件，完成材料草稿 |
| 第2天 | 试测、修订脚本，确认招募名单 |
| 第3–4天 | 每天进行2–3场研究，当天整理关键发现 |
| 第5天 | 合并证据、确定优先问题，召开决策会议 |
适合范围明确、已有原型、招募渠道成熟的验证型研究。
两周的探索研究
第一周用于梳理已有证据、招募和情境访谈；第二周补充不同角色，形成行为模式与机会点，再与业务数据交叉验证。它更适合新产品、复杂B端流程或团队对问题本身还没有共识的情况。
07 可直接复制的用户研究计划模板
| 模块 | 填写内容 |
|---|---|
| 项目与版本 | 研究对象、当前阶段、负责人、日期 |
| 待支持的决定 | 研究结束后要批准、否决或调整什么 |
| 已有证据 | 数据、历史研究、客服和销售反馈、已知假设 |
| 研究目标 | 本轮希望降低的决策风险 |
| 研究问题 | 3–6个可通过证据回答的问题 |
| 参与者 | 角色、经验、频率、场景、排除条件、人数范围 |
| 方法 | 访谈、观察、原型测试、问卷、数据分析及选择理由 |
| 研究材料 | 脚本、任务、原型、同意书、记录表 |
| 时间与责任 | 准备、试测、研究、分析、评审的负责人和节点 |
| 输出 | 立即同步内容、正式交付物、决策会议 |
| 限制与风险 | 样本偏差、招募困难、材料成熟度、敏感信息 |
08 典型场景：为审批产品做一次研究计划
假设团队准备重做“发起审批”流程。业务方希望减少填写时间，设计团队则怀疑真正的问题是用户找不到正确模板。
此时研究目标不应写成“优化审批体验”，而可以写成：确认用户选择模板、理解字段和提交材料时的主要阻力，决定开发前应优先修改入口、表单结构还是帮助机制。
参与者至少覆盖经常发起审批的员工、偶尔发起的员工，以及维护模板的管理员。方法可以组合为：先访谈管理员了解规则，再让发起人用原型完成两个真实任务。最终交付不是一份长报告，而是一张“问题—证据—影响—建议—待决策”的表格。
09 谁负责写，谁负责确认
研究员或产品设计师可以起草，但研究计划不应由一个人关门完成。产品负责人确认待支持的决定，业务方确认用户角色和规则，数据或客服团队补充已有证据，研发确认原型和技术限制。最终负责决策的人必须在研究开始前看过计划，否则研究很容易在结论阶段才暴露目标分歧。
常见问题
用户研究计划需要写多长？
没有固定页数。简单验证一页即可，复杂项目可能需要附招募筛选、脚本和数据处理说明。判断标准不是字数，而是新成员能否据此组织一场研究，并知道哪些结论可以使用。
计划确定后还能改吗？
可以。试测后修改任务、补充样本或收紧问题很正常，但应记录改动原因，避免团队在过程中不断更换目标，最后把不同问题的证据混在一起。
没有专职研究员，产品经理能做吗？
可以做范围明确的访谈和测试，但最好安排一名记录者，并让主持人接受基本训练。涉及敏感人群、医疗金融、高风险决策或复杂统计时，应引入相应专业人员。
10 让研究和设计真正进入产品决策
链接复制成功
