用户研究计划的约束通常集中在五类：研究目标与决策时点、样本与招募条件、时间与排期、预算与人力、合规与隐私。把这些约束先写成可核对的计划字段，再按“锁定不可变约束、调整可变量”的顺序排期，计划才具备可执行性。下文给出一张约束字段表、一套排期步骤、角色分工、完整示例和定稿前的检查清单。
要点总览（TL;DR）
- 用户研究计划的约束集中在五类：研究目标与决策时点、样本与招募条件、时间与排期、预算与人力、合规与隐私，先写成可核对的计划字段再排期。
- 排期按倒推进行：从决策时点推出最晚交付日，再依次确定招募周期、方法与样本量、里程碑与缓冲。
- 先锁定不可变约束（决策时点、合规要求、人群定义），再在配额、方法组合、招募渠道上做取舍，取舍依据是结论能否支撑决策。
- 每类约束指定确认人与交付物，不可变约束变更由决策使用方与研究者共同确认，合规变更须经法务或合规确认，并记录在变更日志。
- 定稿前用完成检查清单逐项核对，目标与决策时点、样本与招募、时间与缓冲、预算与人力、合规与隐私五项未通过即按阻断项处理。
先把约束写成计划字段：一张用户研究计划约束表
用户研究计划出问题，多数时候源于约束停留在口头共识里：产品经理说“月底要结论”，招募同事说“这类用户不好找”，法务说“访谈要签同意书”，但没有人把它们写进同一份计划。可执行的起点，是把这些说法转成字段，每个字段填不上或填不实，就说明对应约束还没有被确认。
下表按五类约束列出字段、填写要求与可变性判断。可变性一栏决定排期时先动谁：标为“不可变”的字段一旦确认，后续调整只能围绕其他字段展开。
| 字段 | 填写要求 | 约束类型 | 可变性 |
|---|---|---|---|
| 研究问题 | 用一句话写清要回答什么，限定在产品与用户场景范围内；列出对应的产品决策 | 目标与决策时点 | 不可变（确认后） |
| 决策用途与决策时点 | 写明结论将被哪项决策使用、决策会议或评审的日期 | 目标与决策时点 | 不可变 |
| 目标人群与配额 | 描述用户特征、使用行为、分层维度及每层人数；说明排除条件 | 样本与招募 | 部分可变（配额可压缩，人群定义不宜放宽） |
| 招募渠道与周期 | 列出渠道、预计触达人数、筛选方式、激励形式与招募所需天数 | 样本与招募 | 可变 |
| 方法与样本量 | 选择访谈、可用性测试、问卷等方法，说明每种方法的样本量与理由 | 样本与招募、预算人力 | 可变（在能支撑结论的前提下调整） |
| 时间窗与里程碑 | 写明启动日、招募完成、数据收集完成、分析完成、交付日 | 时间与排期 | 交付日不可变，中间里程碑可调 |
| 预算与角色 | 列出激励、工具、外部招募等费用，以及研究者、招募执行方、分析支持的人力投入 | 预算与人力 | 可变（需审批） |
| 知情同意与数据处理 | 写明同意方式、录音录像范围、数据存储位置、保存期限、脱敏与销毁安排 | 合规与隐私 | 不可变 |
判断一个字段是否属于不可变约束，可以问两个问题：改动它是否会让研究结论无法支撑原定决策？改动它是否触碰合规底线？任一答案为是，就按不可变处理。其余字段在排期冲突时可以作为调整对象，但调整要留下记录，避免后续复盘时说不清计划为何变形。
按约束排期的操作步骤：从研究问题到可执行时间窗
排期的基本逻辑是倒推：从决策时点往回推交付日、分析期、数据收集期和招募期，每一步都对照约束表检查是否可行。以下四步给出每步的输入、动作、输出与完成标志。
步骤一：确认研究问题与决策时点，倒推最晚交付日
- 输入：约束表中的研究问题、决策用途、决策会议日期。
- 动作：与决策使用方确认结论需要以什么形式、在多长时间内被消化；从决策日倒推，预留评审与修订时间，得到最晚交付日。
- 输出：一句话研究问题、决策时点、最晚交付日。
- 完成标志：决策使用方书面确认交付日与交付形式。
步骤二：确定目标人群与配额，评估招募难度与周期
- 输入：目标人群定义、分层维度、可用招募渠道。
- 动作：按分层维度设定每层人数；向招募执行方询问各渠道的历史响应速度与筛选通过率，估算招募天数；对难招募的层级提前准备备选渠道。
- 输出：配额表、招募周期估算、备选渠道清单。
- 完成标志：招募执行方确认在给定周期内可完成的配额，或明确缺口及补救方案。
步骤三：选择方法与样本量，匹配时间与预算
- 输入：研究问题、配额表、可用时间窗、预算上限。
- 动作：按问题性质选择方法组合；核对每种方法的单场时长、场次数量与激励成本，计算总工时与总费用；若超出时间或预算，优先压缩方法组合或场次，而非放宽人群定义。
- 输出：方法说明、样本量及理由、费用与工时估算。
- 完成标志：方法与样本量能回答研究问题，费用与工时在预算和人力范围内，并获得负责人确认。
步骤四：排里程碑与缓冲，标注依赖与风险点
- 输入：最晚交付日、招募周期、数据收集与分析工时。
- 动作：把启动、招募完成、数据收集完成、分析完成、交付五个节点排入日历；在招募完成与分析完成之间留出缓冲；标注依赖关系，例如招募未完成则数据收集无法启动；列出主要风险点及应对方式。
- 输出：里程碑表、依赖与风险清单。
- 完成标志：每个里程碑有责任人和日期，缓冲时长有依据，风险点有对应预案。
| 里程碑 | 关键产出 | 依赖 | 缓冲建议 |
|---|---|---|---|
| 计划确认 | 约束表定稿、里程碑表 | 决策时点确认 | — |
| 招募完成 | 符合配额的参与者名单 | 招募渠道与筛选标准 | 预留补招时间 |
| 数据收集完成 | 访谈记录、测试录像、问卷数据 | 招募完成、同意书签署 | 预留场次改约空间 |
| 分析完成 | 发现清单、证据摘录 | 数据收集完成 | 预留复核时间 |
| 交付与评审 | 研究报告、决策建议 | 分析完成 | 预留修订轮次 |
当研究计划涉及多个并行项目或跨团队评审时，任务、里程碑和评审节点需要有共同的承载位置，否则排期表容易停留在个人文档里。ONES 项目协作可以承载研究任务、里程碑与评审流程，让招募、数据收集、分析各节点的责任人和状态在同一处可见，便于在约束变更时同步调整。工具承担的是协作与记录，约束的判断标准仍由研究团队和决策使用方确定。
角色与交付物分工：谁对哪类约束负责
约束表填完只是第一步，每类约束还需要明确确认人和交付物，否则计划在执行中会因无人拍板而反复。下表按角色列出职责范围与对应交付物。
| 角色 | 负责的约束 | 交付物 |
|---|---|---|
| 研究者 | 研究问题、方法与样本量、分析计划 | 研究方案、讨论提纲或测试脚本、分析框架、研究报告 |
| 产品经理 | 决策用途与决策时点 | 决策问题说明、交付日确认、结论采纳反馈 |
| 设计 | 测试材料与场景设定 | 原型或可用版本、任务脚本、场景说明 |
| 数据/分析 | 问卷设计与数据口径、分析支持 | 问卷题目、数据清洗规则、分析结果 |
| 法务或合规 | 知情同意、数据处理与保存 | 同意书模板、数据处理说明、合规确认意见 |
| 招募执行方 | 目标人群触达、配额完成、激励发放 | 参与者名单、筛选记录、招募进度报告 |
约束变更需要审批与记录。可行的做法是：不可变约束的变更由决策使用方与研究者共同确认，合规相关变更须经法务或合规确认；可变约束的调整由研究者判断并记录在计划变更日志中，写明调整原因、影响范围与新的里程碑日期。变更日志与研究计划放在同一处，评审时可以直接对照原始约束与最终执行情况。
示例：一次可用性研究计划的约束落地
以下为演示情景，用于说明约束表、排期与分工如何组合，不代表任何具体组织的真实项目。
背景：某产品团队计划在版本发布前完成一次可用性研究，验证新流程是否可被目标用户独立完成。不可变约束有三项：决策评审定在第四周周五，结论须在此之前交付；参与者须签署知情同意书，测试过程录像仅用于内部分析并设定保存期限；目标人群须为近三个月内使用过同类流程的用户。
可调整约束的取舍过程：原计划招募十二名参与者、分三个用户分层。招募执行方反馈其中一个分层响应缓慢，按原配额需要三周才能完成。研究者的处理是压缩该分层人数、增加另外两个分层的场次，并把部分远程场次改为现场场次以缩短筛选周期；方法上保留任务测试加事后访谈的组合，问卷部分缩减为短版，用于补充背景信息。人群定义与合规要求保持不变。
| 字段 | 示例填写 |
|---|---|
| 研究问题 | 目标用户能否在没有引导的情况下独立完成新流程 |
| 决策用途与时点 | 版本发布评审，第四周周五 |
| 目标人群与配额 | 近三个月使用过同类流程的用户，两个主要分层各若干人，难招募分层压缩人数 |
| 方法与样本量 | 任务测试加事后访谈，辅以短版问卷 |
| 时间窗与里程碑 | 第一周启动与招募，第二周数据收集，第三周分析，第四周交付与评审 |
| 预算与角色 | 激励与远程测试工具费用；研究者主导，招募执行方支持，设计提供原型 |
| 合规与隐私 | 签署同意书，录像限内部使用并设定保存期限，报告脱敏 |
这个示例体现的规律是：先锁定决策时点与合规要求，再在样本配额、方法组合和招募渠道上做取舍；取舍的依据是结论是否仍能支撑决策，而非单纯压缩工作量。适用边界在于，当研究问题本身依赖特定细分人群时，压缩该人群配额会削弱结论效力，此时应改为调整交付范围或与决策使用方重新约定时点，而不是勉强按原计划执行。
完成检查：计划可执行前的核对项
计划定稿前，用下表逐项核对。每项给出通过标准，未达到通过标准的条目按阻断项处理，解决后才能进入执行。
| 核对项 | 通过标准 | 未通过时的处理 |
|---|---|---|
| 目标与决策时点 | 研究问题一句话可读，决策用途与决策日期已由使用方确认 | 阻断：回到步骤一重新确认 |
| 样本与招募条件 | 配额表完整，招募执行方确认周期内可完成，或有明确补救方案 | 阻断：调整配额或渠道后再排期 |
| 时间窗与缓冲 | 五个里程碑均有责任人与日期，招募与分析节点留有缓冲 | 阻断：补齐里程碑与缓冲 |
| 预算与人力 | 费用与工时估算在批准范围内，各角色投入已确认 | 阻断：超支部分需审批或缩减方法组合 |
| 合规与隐私 | 同意方式、数据存储、保存期限、脱敏与销毁安排均已写明并经确认 | 阻断：合规未确认前不启动数据收集 |
| 变更记录方式 | 变更日志已建立，审批人与记录位置明确 | 可补正：执行前补齐 |
五项阻断项全部通过，计划即可进入执行；执行过程中出现约束变更，按变更记录方式更新计划并同步相关角色。把这张检查表与约束表、里程碑表放在同一份计划文档中，下一次研究可以直接复用结构，只替换具体内容。
常见问题
研究问题已经确定，但决策时点一直定不下来，计划还能先往下排吗？
可以先把其他字段填起来，但里程碑日期无法最终确定。决策时点决定最晚交付日，交付日又决定招募、数据收集和分析的时间窗，这一环缺失时排出的日期只是假设。可行的做法是：先按一个暂定的决策日期排出草案，同时把“决策时点确认”标为计划中的阻断项，在决策使用方确认后统一调整后续节点。草案阶段可以并行推进招募渠道评估和方法设计，这两项不依赖具体日期。
招募执行方反馈某个用户分层招不满，应该压缩配额还是延长招募期？
先判断该分层对研究结论的作用。如果研究问题本身依赖这类用户的特定行为，压缩配额会削弱结论效力，此时更稳妥的做法是与决策使用方重新约定交付时点，或缩小研究问题的范围，而不是勉强按原计划执行。如果该分层只是补充性样本，可以压缩人数、增加其他分层场次，并在计划中记录调整原因和影响范围。无论哪种处理，都要在变更日志中写明，便于评审时对照原始约束。
合规要求在研究进行中发生变化，已收集的数据怎么处理？
合规属于不可变约束，发生变化时应暂停新的数据收集，先由法务或合规确认已收集数据的继续使用条件、存储方式和保存期限。根据确认结果，可能需要补充告知参与者、调整脱敏方式或提前销毁部分数据。处理完成后更新计划中的知情同意与数据处理字段，并在变更日志中记录变更原因、影响范围和新的里程碑日期，再恢复执行。
多个研究项目并行时，里程碑和评审节点怎么避免各自为政？
关键是把任务、里程碑和评审节点放在共同的承载位置，让各项目的责任人和状态在同一处可见。ONES 项目协作可以承载研究任务、里程碑与评审流程，便于在某个项目的约束变更时同步调整相关排期。工具解决的是协作与记录问题，约束的判断标准仍由各研究团队和决策使用方确定，跨项目冲突时按决策时点的先后和结论影响范围协商优先级。
计划已经通过检查清单，执行中还需要复核哪些内容？
检查清单通过只代表计划具备执行条件，执行中需要持续关注三类变化：招募进度是否偏离配额、数据收集是否按里程碑完成、合规安排是否仍然有效。出现约束变更时，按变更记录方式更新计划并同步相关角色；不可变约束的变更须重新确认，不能只在执行层面自行调整。研究结束后，把实际执行情况与原始约束对照，作为下一次研究复用计划结构的依据。
