制定用户研究计划，先写清研究问题与决策用途，再确定研究对象、方法和样本，排出时间与资源，明确角色分工与交付物，最后设置评审、伦理与完成检查。核心产物是一份可执行的研究计划文档。本文给出字段框架、六步流程、角色对照、两周访谈示例和定稿检查清单；研究任务的排期与评审跟踪也可以放到ONES这类研发协作平台中承载。
要点总览（TL;DR）
- 用户研究计划的核心产物是一份可执行文档，至少写清研究问题与决策用途、目标与成功标准、方法与样本、招募与排期、角色与交付物、风险与合规六类字段。
- 制定流程分六步：确认决策问题、转成研究问题与假设、选择方法与样本、招募与安排场次、排期与资源、评审并冻结版本，每步都有输入、输出和完成标志。
- 角色分工要落到决策权和交付物上，研究负责人、产品经理、设计师、数据分析、法务或合规各自确认什么、交付什么，用对照表写清楚。
- 两周访谈示例展示了从计划草稿到研究关闭的按天排期，排期需标注依赖项并留备用候选人和缓冲时间。
- 定稿前按检查清单逐项核对问题关联性、方法与样本、排期可行性、伦理合规和验收标准，未通过项回到对应步骤修订。
一份可执行的用户研究计划包含哪些内容
研究计划的价值在于让参与者在动手招募用户之前，对“为什么研究、研究谁、怎么研究、谁来交付、何时完成”形成同一份书面共识。计划文档不必很长，但每个字段都要写到能被他人执行和核对的颗粒度。下表给出建议的字段框架，可按研究规模裁剪，不建议整项省略。
| 字段 | 填写要求 | 负责人 |
|---|---|---|
| 研究问题与决策用途 | 写明本研究要支持哪个产品决策，列出1–3个核心研究问题；每个问题说明答案将影响什么动作，例如功能取舍、流程改版或定价方向 | 研究负责人与产品经理共同确认 |
| 研究目标与成功标准 | 把目标写成可判断是否达成的表述，例如“识别新用户在首次配置环节的主要受阻点，并给出优先级排序”；成功标准说明需要多少有效样本、覆盖哪些用户类型 | 研究负责人 |
| 方法与样本设计 | 说明采用访谈、可用性测试、问卷、日志分析或组合方法，给出选择理由；写明样本量、招募条件、分组方式和排除条件 | 研究负责人，设计师参与方法评审 |
| 招募、激励与排期 | 列出招募渠道、筛选问卷、场次安排、每场时长、激励形式与发放方式；排期精确到日期和时段，标注依赖项 | 研究负责人或专职招募协调人 |
| 角色分工与交付物 | 逐项列出谁负责招募、主持、记录、分析、评审和汇报，每个角色对应具体交付物与截止时间 | 研究负责人统筹 |
| 风险、伦理与合规 | 说明知情同意方式、数据脱敏与存储要求、录音录像授权、敏感问题的处理预案，以及可能影响排期的风险与应对 | 研究负责人，法务或合规确认 |
字段填写完成后，建议由产品经理确认“决策用途”一栏，由法务或合规确认隐私相关条款，再由研究负责人冻结版本。计划文档一旦冻结，后续变更走版本记录，避免执行中途口径漂移。
从研究问题到排期：制定计划的六个步骤
六个步骤按输入、动作、输出和完成标志推进，前一步的输出是后一步的输入。规模较小的研究可以合并部分动作，但决策问题确认和计划评审两个环节建议保留。
第一步：确认决策问题与利益相关方
输入是产品当前面临的决策或不确定性。动作是与产品经理、设计师及相关业务方开一次范围对齐会，明确本研究要回答什么、不回答什么，并列出利益相关方及其关注点。输出是一页决策问题说明和利益相关方名单。完成标志是所有关键利益相关方对“本研究支持哪个决策”没有分歧。
第二步：把问题转成可验证的研究问题与假设
输入是决策问题说明。动作是把宽泛的问题拆成具体、可通过用户行为或表述验证的研究问题，并为每个问题写出初步假设。例如把“新用户上手难”拆成“新用户在首次配置时卡在哪些步骤、原因是什么”，假设可以是“配置项命名与用户心智不一致导致停顿”。输出是研究问题与假设清单。完成标志是每个研究问题都能对应到一种数据收集方式。
第三步：选择方法与样本量并说明取舍
输入是研究问题与假设清单。动作是根据问题性质选择方法：探索原因用访谈，评估操作路径用可用性测试，验证分布用问卷，观察真实行为用日志或埋点分析。同时确定样本量、用户类型和招募条件，并写明为什么这样取舍。输出是方法与样本设计说明。完成标志是方法能覆盖全部核心研究问题，样本条件可被招募人员直接执行。
第四步：招募用户与安排场次
输入是样本设计说明。动作是编写筛选问卷、发布招募、筛选候选人、确认场次并发送知情同意材料。输出是确认的参与者名单与场次表。完成标志是每个用户类型都有满足数量的确认参与者，并留有备用候选人。
第五步：排期、资源与依赖
输入是场次表和交付物清单。动作是把招募、访谈、分析、汇报排入日历，标注设备、会议室、记录工具等资源需求，识别依赖项，例如设计稿定稿时间、数据导出权限审批。输出是带里程碑的排期表。完成标志是每个里程碑有负责人和日期，关键依赖已确认可用。
第六步：评审与冻结计划版本
输入是完整计划草稿。动作是组织评审，逐项核对研究问题与决策的关联、方法与样本的合理性、排期可行性以及伦理合规条款，记录修改意见并修订。输出是冻结版本的研究计划。完成标志是评审通过、版本号确定，并通知全部参与者。
计划冻结后，招募进度、场次完成情况、分析产出和评审结论需要持续跟踪。这类任务排期、文档评审和交付物状态可以在ONES中建立对应工作项与评审流程，让研究负责人和产品经理在同一处看到计划执行到哪一步；具体配置方式按团队现有协作习惯确定。
谁负责什么：角色分工与交付物对照
研究计划执行中最常见的问题是职责空转：有人以为别人会招募，有人以为分析结论会自动汇总。用一张角色对照表把决策权、执行责任和交付物写清楚，可以显著减少返工。
| 角色 | 主要职责 | 决策权 | 交付物 |
|---|---|---|---|
| 研究负责人 | 统筹计划制定、方法设计、执行推进与结论输出 | 方法选择、样本设计、分析口径 | 研究计划、访谈提纲、分析报告 |
| 产品经理 | 提供决策背景，确认研究问题与优先级，参与结论评审 | 研究问题优先级、决策用途确认 | 决策问题说明、需求背景材料、评审意见 |
| 设计师 | 提供原型或现有界面，参与可用性测试设计，协助解读体验问题 | 测试任务与原型版本确认 | 测试用原型、任务脚本、设计侧改进建议 |
| 数据分析 | 提供行为数据、协助抽样与结果交叉验证 | 数据口径与提取方式 | 行为数据摘要、样本分布说明 |
| 法务或合规 | 审核知情同意、隐私条款与数据存储方式 | 合规条款是否通过 | 知情同意模板、合规审核意见 |
评审与签核节点建议至少设置两个：计划冻结前的评审，确认问题、方法、排期与合规；研究结束后的结论评审，确认发现是否回应了原始研究问题、建议是否有依据。两个节点都应有明确的通过标准和记录人，避免评审停留在口头确认。
示例：一个两周用户访谈研究计划怎么排
以下为演示情景，用于说明计划文档如何填写和排期，不代表真实项目结论，也不作为统一排期要求。
研究问题与假设示例
决策背景是某协作产品准备改版首次配置流程。研究问题设定为：新用户在首次配置中遇到哪些阻碍；这些阻碍与用户对配置项的理解有什么关系。假设为：配置项命名偏技术化，导致用户跳过或随意填写，进而影响后续使用。成功标准是完成8–10名新用户的访谈，覆盖两类使用场景。
方法与样本示例
方法采用半结构化访谈结合界面走查，每场45分钟。样本为近30天内注册、完成首次配置的用户，按使用场景分为两组，每组4–5人，另备2名候选人。招募通过产品内邀请和用户社群进行，激励为约定形式的礼品卡，发放时间安排在访谈结束后三个工作日内。
按天排期与里程碑示例
| 时间 | 任务 | 里程碑 |
|---|---|---|
| 第1–2天 | 确认研究问题与假设，完成方法与样本设计，起草访谈提纲 | 计划草稿完成 |
| 第3天 | 计划评审，法务确认知情同意模板，冻结版本 | 计划冻结 |
| 第4–6天 | 发布招募、筛选候选人、确认场次 | 参与者名单确认 |
| 第7–10天 | 执行访谈，每天2–3场，当天整理记录 | 访谈全部完成 |
| 第11–12天 | 编码与主题分析，交叉核对行为数据 | 分析初稿 |
| 第13天 | 结论评审，产品经理与设计师确认发现与建议 | 评审通过 |
| 第14天 | 输出最终报告并归档原始记录 | 研究关闭 |
交付物与验收示例
交付物包括冻结版研究计划、访谈提纲、场次记录、分析报告和原始记录归档包。验收标准为：报告中的每条主要发现都能追溯到具体访谈记录；建议部分标明对应的研究问题；产品经理与设计师在评审记录中确认结论可用于改版决策。
计划评审与完成检查清单
计划定稿前，按下表逐项核对。每项给出通过标准，未通过的项回到对应步骤修订，不建议带着未决项冻结版本。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 问题与决策关联性 | 每个研究问题都能对应一个具体产品决策；利益相关方已确认决策用途 | 研究负责人与产品经理 |
| 方法与样本合理性 | 方法能覆盖全部核心研究问题；样本量、用户类型和排除条件写明且可执行；取舍理由有记录 | 研究负责人 |
| 排期与资源可行性 | 每个里程碑有负责人和日期；招募、设备、数据权限等依赖已确认；留有备用候选人和缓冲时间 | 研究负责人 |
| 伦理、隐私与知情同意 | 知情同意方式已确定；录音录像授权、数据脱敏与存储要求写明；敏感问题有处理预案；法务或合规已确认 | 研究负责人与法务或合规 |
| 交付物与验收标准 | 交付物清单完整，每项有截止时间和验收方式；结论评审节点已排入计划 | 研究负责人 |
检查清单通过后，冻结计划版本并通知全部参与者。执行过程中如遇样本不足、排期冲突或合规要求变化，按变更记录更新计划，并在结论评审时说明变更对研究结论的影响。这样一份计划既能指导执行，也能在事后说明研究结论的边界。
常见问题
研究问题还没定清楚，可以先开始招募用户吗？
不建议。招募条件、筛选问卷和访谈提纲都依赖研究问题与假设，问题未定时招募容易招到不匹配的用户，场次安排也可能白费。更稳妥的做法是先完成决策问题确认和假设拆解，再进入招募。如果排期紧张，可以把招募渠道调研、候选人池积累等准备工作提前，正式发布招募仍放在研究问题冻结之后。
样本量到底定多少合适，计划里要写死吗？
计划里应写明目标样本量、用户类型分布和排除条件，并说明取舍理由，而不是只写一个数字。探索性访谈通常以能覆盖主要用户类型、出现信息饱和为判断依据；可用性测试按任务路径和用户分组确定；问卷则要考虑分组分析所需的最小样本。计划冻结后如需调整样本量，走变更记录，并在结论评审时说明对结论范围的影响。
计划执行中途排期被打乱，怎么处理？
先判断影响的是哪个里程碑：招募延迟影响场次，场次压缩影响分析时间，评审推迟影响结论交付。处理方式是在计划中更新日期和依赖项，记录变更原因，并评估是否削减研究范围或增加备用候选人。变更后要同步通知全部参与者，避免各方按旧版本推进。结论评审时应说明变更对研究结论边界的影响。
小团队没有专职研究负责人，角色怎么分？
可以由产品经理兼任研究负责人，但建议把方法设计、主持访谈和分析口径这几项决策权明确到具体的人，避免多人同时改动。设计师可以承担测试任务脚本和原型准备，数据分析承担行为数据提取与交叉验证，合规条款由团队内负责隐私事务的人确认。角色可以合并，交付物和截止时间仍要逐项落到人名。
研究计划需要每次评审都走正式签核吗？
取决于研究影响的决策范围。涉及改版方向、定价或跨团队资源投入的研究，建议保留计划冻结评审和结论评审两个签核节点；范围小、周期短的内部探索可以简化评审形式，但研究问题与决策用途的确认、知情同意与数据处理的确认仍要留下书面记录。评审记录人应固定，避免口头确认后无人可追溯。
