用户研究协作要解决的核心问题，是让研究从个人动作变成可交接的团队流程。本文按“定义研究任务—跑通五个环节—明确角色交付物—示例走查—落地检查”的顺序展开，适用于产品团队建立或梳理用户研究协作机制。文中会说明每个环节的输入、动作、输出和完成标志，并在流程衔接处简要提及ONES可承载的协作方式。
要点总览（TL;DR）
- 用户研究协作的起点是一份可交接的研究任务说明，写清研究问题、对应决策、目标用户、方法、时间窗和决策人，由发起方起草、决策人确认后进入执行。
- 流程按招募与排期、执行、分析、沉淀、转化五个环节推进，每个环节明确输入、动作、输出和完成标志，招募完成标志是样本条件与知情同意落实，而非访谈开始。
- 角色分工按研究者、产品经理、设计师、数据分析、业务方划分，每个角色有明确交付物和交接时点，并指定评审与确认的决策人，避免结论无人认领。
- 判断协作是否跑通，可从研究任务说明是否齐全、记录与证据是否可追溯、洞察是否被需求或决策引用三方面核对，常见断点为招募延期、记录缺失和结论无人认领。
- 建议先在一个研究议题上完整走通闭环，再扩展到多项目并行；团队规模和研究频次不同时，字段和评审节点可相应简化或加强。
用户研究协作先定什么：研究问题与决策用途
协作流程的起点是一份可交接的研究任务说明。研究诉求往往以“想了解一下用户”这类模糊表述出现，直接进入招募和执行，后续很容易出现样本偏离、结论无人使用的情况。把诉求转成任务，关键是先回答两个问题：这项研究要支持哪个具体决策，以及结论由谁拍板采用。
研究问题与决策用途需要一一对应。比如“新版结算流程是否上线”对应的是流程可用性与关键阻碍点研究，“下季度优先做哪个功能”对应的是需求优先级研究。决策不同，研究对象、方法和样本条件都会随之变化。研究任务说明建议至少写清以下字段：
- 研究问题：用一句话描述要回答的问题，避免多个问题混在一项研究里；
- 对应决策：结论将用于哪次会议、哪个版本或哪项规划；
- 目标用户：人群特征、使用场景、样本量与招募条件；
- 研究方法：访谈、可用性测试、问卷或组合方式，以及选择理由；
- 时间窗：招募、执行、分析、交付各阶段的日期；
- 决策人：对研究范围和最终结论负责确认的人。
发起与确认的分工要固定下来。通常由产品经理或研究者起草任务说明，决策人确认研究范围与时间窗后进入执行；涉及多个业务方时，由决策人在启动前完成一次范围对齐，避免执行中途反复追加问题。完成标志是这份说明能被另一个没参与讨论的同事读懂并据此开展招募。
从招募到沉淀：用户研究协作的五个环节与操作步骤
五个环节按“招募与排期—执行—分析—沉淀—转化”推进，每个环节都有明确的输入、动作、输出和完成标志。下表给出操作步骤，便于团队对照执行。
| 环节 | 输入 | 关键动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 招募与排期 | 研究任务说明中的目标用户与样本条件 | 确定招募渠道，筛选候选人，安排时间，完成知情同意 | 受访者名单与排期表、知情同意记录 | 样本条件、渠道、时间、同意均已落实 |
| 执行 | 排期表、访谈或测试脚本、记录模板 | 按主持、记录、观察分工开展访谈或可用性测试，同步填写记录 | 逐场次的原始记录与关键片段 | 每场次记录完整，关键语句有原文或时间点 |
| 分析 | 原始记录 | 编码、归类、合并相似问题，形成洞察并标注证据来源 | 编码表与洞察初稿 | 每条洞察都能对应到具体记录片段 |
| 沉淀 | 洞察初稿与原始记录 | 整理洞察文档，关联证据片段与原始记录，标注适用范围 | 可检索的洞察文档 | 文档中的结论可回溯到原始记录 |
| 转化 | 洞察文档 | 把洞察转成需求建议，写明依据与优先级理由，提交需求池或评审 | 需求建议条目 | 建议进入需求池或评审议程，并有明确接收人 |
招募与排期的完成标志是准备就绪，访谈开始并不算完成。样本条件要在招募前写清，包括使用频率、角色、设备环境等筛选维度；知情同意应在访谈前完成，说明记录用途与信息使用范围。
执行环节建议固定主持、记录、观察三种分工。主持人负责提问与追问，记录人按统一模板记录原话、行为与时间点，观察人关注主持遗漏的信号并在结束后补充。统一模板能减少记录缺失，也方便后续分析时横向对比。
分析环节以原始记录为证据基础。先对记录做编码，把相似表述归到同一主题，再合并成洞察；每条洞察标注对应的记录片段编号，避免结论与证据脱节。沉淀环节把洞察文档与原始记录建立关联，写明研究背景、样本情况和适用边界，让未参与研究的同事也能判断结论能用在哪里。
转化环节决定研究是否真正进入决策。需求建议要写明来自哪条洞察、影响哪些用户、建议的处理方式，并指定接收人。研究任务、记录文档与需求建议如果分散在不同工具里，交接容易断档；在ONES中，可以把研究任务作为工作项管理，把访谈记录与洞察文档放在同一项目空间内关联，需求建议直接进入需求池流转，减少跨工具搬运造成的信息丢失。具体字段与权限配置需结合团队实际情况设定。
角色与交付物：谁负责什么、交什么
角色分工的关键是每个角色都有明确交付物和交接时点，并指定评审与确认的决策人。下表按角色列出职责、交付物与交接时点，团队可根据研究频次增减角色。
| 角色 | 主要职责 | 关键交付物 | 交接时点 |
|---|---|---|---|
| 研究者 | 设计研究方案，主持执行，主导分析与洞察撰写 | 研究任务说明、访谈脚本、洞察文档 | 执行前交付脚本，分析后交付洞察文档 |
| 产品经理 | 提出研究诉求，确认决策用途，承接需求建议 | 研究诉求、需求建议条目 | 启动前确认范围，转化环节接收建议 |
| 设计师 | 提供原型或界面材料，参与可用性测试观察 | 测试用原型、设计侧观察记录 | 执行前交付材料，执行后补充观察 |
| 数据分析 | 提供行为数据佐证，协助样本分层与结论校验 | 数据摘要、样本分层建议 | 分析环节提供，评审前完成校验 |
| 业务方 | 提供业务背景与用户线索，参与结论评审 | 业务背景说明、评审意见 | 启动前提供背景，评审会上给出意见 |
评审与确认的决策人应在研究任务说明中提前指定。决策人负责确认研究范围、参加结论评审、对需求建议给出采纳或搁置的明确意见。没有指定决策人时，洞察容易停留在文档里无人认领，这是协作断档的常见原因。
一个研究议题的协作示例
以下为演示情景：某产品团队计划改版订单确认页，改版前安排一轮用户访谈，用于判断当前页面的主要阻碍点。示例中的字段填写与流转过程用于说明流程如何跑通。
研究任务说明的填写示例：研究问题为“用户在订单确认页遇到哪些阻碍导致放弃支付”；对应决策为“下个版本改版方案评审”；目标用户为近三个月内有下单行为、且有过放弃支付记录的用户，样本8至10人；方法为半结构化访谈结合页面走查；时间窗为两周，第一周招募与执行，第二周分析与评审；决策人为产品负责人。
执行阶段由研究者主持，产品经理记录，设计师观察。记录模板按“用户背景—操作路径—卡点描述—原话摘录”四栏填写，每场访谈结束后当天整理，避免记忆偏差。分析阶段把记录编码为“信息不清晰”“支付方式困惑”“信任顾虑”等主题，每条洞察标注对应的场次与片段编号。
洞察文档完成后，研究者把“支付方式说明不清晰”等结论转成需求建议，写明影响的用户范围与建议改法，提交至需求池并列入改版评审议程。评审会上，产品负责人逐条对照洞察文档中的证据片段讨论，对采纳的建议标注处理版本，对搁置的建议记录原因。整个过程从任务说明到需求建议形成一条可追溯的链路。
协作落地检查：完成标志与常见断点
判断用户研究协作是否跑通，可以按以下清单逐项核对。建议先在一个研究议题上完整走通闭环，再扩展到多项目并行；团队规模和研究频次不同时，字段和评审节点可相应简化或加强。
- 研究任务说明是否写清研究问题、对应决策、目标用户、方法、时间窗和决策人；
- 招募是否完成样本条件确认与知情同意，排期是否留有缓冲；
- 每场次记录是否完整，关键结论是否有原文或片段编号支撑；
- 洞察文档是否与原始记录关联，是否写明适用边界；
- 需求建议是否进入需求池或评审议程，是否有明确接收人；
- 评审是否由指定决策人参加，采纳与搁置是否都有记录。
常见断点集中在三处。招募延期通常源于样本条件过窄或渠道单一，可在任务说明阶段预留备选渠道；记录缺失多发生在分工不清或模板不统一时，固定主持、记录、观察分工并当天整理记录能明显改善；结论无人认领则与决策人缺位有关，在启动前指定决策人并在评审中形成明确意见，可以让每条洞察都有去向。
常见问题
研究任务说明由谁起草、谁确认？如果决策人中途换人怎么办？
通常由产品经理或研究者起草研究任务说明，决策人确认研究范围与时间窗后进入执行。如果决策人中途换人，应在执行前重新确认一次研究问题与对应决策，并在任务说明中更新决策人字段；若已进入执行阶段，由新决策人参加结论评审并对需求建议给出明确意见，避免结论无人认领。
访谈记录和洞察文档一定要关联到原始记录吗？团队人少时能否简化？
建议保留关联。每条洞察标注对应的记录片段编号，能让未参与研究的同事判断结论的适用范围，评审时也便于用证据支撑讨论。团队人少或研究频次低时，可以简化记录模板和编码步骤，但洞察与原始记录的对应关系仍应保留，否则后续追溯和复用会变得困难。
需求建议进入需求池后，研究协作就算结束了吗？
需求建议进入需求池或评审议程，并有明确接收人，是转化环节的完成标志。协作并未就此结束：评审会上决策人需对建议给出采纳或搁置的明确意见，采纳的建议标注处理版本，搁置的记录原因。这些记录让研究结论与后续决策形成可追溯的链路，也方便下一轮研究参考。
招募经常延期，有哪些可操作的改善办法？
招募延期通常源于样本条件过窄或渠道单一。可在研究任务说明阶段写清筛选维度，并预留备选渠道；排期时留出缓冲时间，把知情同意和候选人确认放在执行前完成。如果目标用户群体较小，可适当放宽非核心筛选条件，或在分析时标注样本局限，而不是反复推迟执行。
团队刚开始建立用户研究协作流程，应该从哪个环节入手？
建议先从一个具体研究议题入手，完整走通任务说明、招募执行、分析沉淀到需求建议的闭环，再逐步扩展到多项目并行。起步阶段可先固定研究任务说明的关键字段和一次结论评审，角色分工和记录模板随实践调整。流程跑通一轮后，再根据实际断点补充检查项和交接规则。
