用户研究协作中，责任与交付要求模糊常表现为：访谈记录没人认领、洞察报告反复返工、被访者协调与执行脱节、评审意见散落在聊天里。本文给出一套可落地的机制：先按角色和交付物建立对应关系，再按研究阶段拆解动作与交接，用研究任务卡和交付清单固定记录，最后用检查清单核对是否真正明确。文中也会说明这类责任分工如何借助ONES等协作工具承载任务与文档状态。
要点总览（TL;DR）
- 先把“大家一起做研究”拆成决策人、研究执行人、被访者协调人、评审人、交付与跟进人五类角色，每个角色对应看得见的产物，角色可兼任但职责要分别写明。
- 按启动、执行、分析、交付四个阶段排开输入、动作、输出和完成标志，达到标志才进入下一阶段，交接由接收方核对完成标准。
- 用研究任务卡固定“谁负责、交什么”，用交付清单逐项核对“交到什么程度算完成”，责任变更在任务卡中留痕。
- 上线前从角色覆盖、职责冲突、交付物可验收、交接与评审节点、记录可追溯五个方面逐项检查，试运行一个项目后再小幅调整。
责任与交付要求先落到哪几类角色和产物
明确责任的第一步，是把“大家一起做研究”拆成可指派的角色，并让每个角色对应看得见的产物。用户研究协作通常涉及五类角色：决策人、研究执行人、被访者协调人、评审人、交付与跟进人。角色可以一人兼任，但职责边界要在启动时写清，避免出现“都参与、都不负责”的情况。
决策人通常是产品负责人或业务负责人，负责确认研究问题、拍板研究范围、在关键节点做取舍；研究执行人负责研究设计、访谈或测试执行、记录与初步分析；被访者协调人负责招募、排期、知情同意与激励发放；评审人负责对研究方案和洞察结论提出意见；交付与跟进人负责报告撰写、发布以及后续行动项的跟踪。小团队中执行人与交付人常为同一人，此时仍需在任务卡中分别写明两项职责。
每类角色的关键交付物不同。决策人产出的是确认后的研究问题与范围；执行人产出研究方案、访谈或测试记录、分析材料；协调人产出被访者名单与排期表；评审人产出评审意见与结论确认；交付与跟进人产出研究报告与行动项清单。把这些对应关系列成表，团队就能快速判断某项工作该找谁。
| 角色 | 职责 | 关键产出 | 交接对象 |
|---|---|---|---|
| 决策人 | 确认研究问题与范围，关键节点做取舍 | 研究问题清单、范围确认记录 | 研究执行人 |
| 研究执行人 | 研究设计、执行、记录与初步分析 | 研究方案、访谈/测试记录、分析材料 | 评审人、交付人 |
| 被访者协调人 | 招募、排期、知情同意、激励发放 | 被访者名单、排期表、同意记录 | 研究执行人 |
| 评审人 | 评审方案与结论，提出修改意见 | 评审意见、结论确认记录 | 研究执行人、交付人 |
| 交付与跟进人 | 报告撰写、发布、行动项跟踪 | 研究报告、行动项清单 | 决策人、相关业务方 |
责任与交付要求要写清的最小字段包括：交付物名称、内容要求、格式、完成标准、负责人、交接时点与接收方。其中完成标准最关键，要写成可验收的表述，例如“访谈记录覆盖全部提纲问题，并附关键原话摘录”，而不是“记录完整”。字段缺失时，交付物在交接环节最容易产生争议。
按研究阶段拆解责任与交付步骤
角色框架建立后，需要按时间顺序把动作、输入、输出和交接点排开。用户研究一般分为启动、执行、分析、交付四个阶段，每个阶段都有明确的完成标志，达到标志才进入下一阶段，责任才不会在阶段之间悬空。
启动阶段的输入是业务问题与决策人诉求，动作包括明确研究问题、确定研究范围与方法、指定各角色、列出交付物清单，输出是经决策人确认的研究任务卡。完成标志是任务卡上的角色、交付物和时间节点均已填写并获得确认，交接时点安排在启动会上。
执行阶段的输入是研究方案与被访者排期，动作包括招募与排期确认、执行访谈或可用性测试、同步记录，输出是完整的访谈或测试记录与被访者信息表。完成标志是所有计划场次执行完毕、记录归档且执行人自检通过，交接时点是执行结束后的记录移交。
分析阶段的输入是执行阶段记录，动作包括编码整理、提炼洞察、形成结论草案，输出是分析材料与洞察结论草案。完成标志是评审人对结论草案给出书面意见并确认，交接时点是评审会。
交付阶段的输入是确认后的结论，动作包括撰写报告、发布、登记行动项并指定跟进人，输出是研究报告与行动项清单。完成标志是报告发布且每个行动项都有负责人和截止时间，交接时点是交付评审或发布会议。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 启动 | 业务问题、决策人诉求 | 明确研究问题与范围，指定角色，列交付物 | 研究任务卡 | 任务卡确认通过 | 决策人、研究执行人 |
| 执行 | 研究方案、被访者排期 | 招募排期、执行访谈或测试、同步记录 | 访谈/测试记录、被访者信息表 | 计划场次完成、记录归档 | 被访者协调人、研究执行人 |
| 分析 | 执行阶段记录 | 编码整理、提炼洞察、形成结论草案 | 分析材料、结论草案 | 评审意见书面确认 | 研究执行人、评审人 |
| 交付 | 确认后的结论 | 撰写报告、发布、登记行动项 | 研究报告、行动项清单 | 报告发布、行动项有负责人 | 交付与跟进人 |
阶段拆解的价值在于让交接有明确时点。每次交接由接收方核对交付物是否达到完成标准，核对结果记录在案，未达标的退回补充，避免问题累积到报告阶段才暴露。
用研究任务卡和交付清单固定责任
流程需要载体，否则责任只停留在会议口头约定。研究任务卡用于固定“这项研究由谁负责、交什么”，交付清单用于逐项核对“交到什么程度算完成”，两者配合使用，形成可追溯的记录。
研究任务卡建议包含以下字段：研究目标、研究问题、决策人、研究执行人、被访者协调人、评审人、交付与跟进人、关键时间节点、交付物清单、变更记录。填写时，研究目标用一句话说明要支持的业务决策；研究问题列出待验证的具体问题；角色字段写姓名而非岗位；交付物清单与交付清单条目一一对应；变更记录留空，后续调整时填写。
交付清单按阶段列条目，每条包含：交付物名称、所属阶段、负责人、截止时间、验收人、完成标准、状态。完成标准要写成可判断的句子，例如“报告包含研究问题回应、关键发现、原话证据和行动建议四部分”。状态可用“待开始、进行中、待验收、已通过”四档，交接时由验收人更新。
责任变更需要有记录。人员调整、范围变化或时间推迟时，在任务卡的变更记录中注明变更内容、原因、生效时间和影响范围，并同步更新交付清单的负责人与截止时间。口头调整容易造成责任悬空，书面记录能让后续追溯有据可依。
| 文档 | 字段/条目 | 填写要点 |
|---|---|---|
| 研究任务卡 | 研究目标、研究问题、五类角色、时间节点、交付物清单、变更记录 | 角色写姓名，交付物与清单对应，变更留痕 |
| 交付清单 | 交付物名称、阶段、负责人、截止时间、验收人、完成标准、状态 | 完成标准可判断，状态由验收人更新 |
一个用户访谈项目的责任分工示例
以下为一个产品团队开展新功能用户访谈的演示情景，用于说明前述方法如何落地，不代表真实项目数据。项目目标是为下一版本的信息架构调整提供依据，计划访谈8名活跃用户。
角色分配为：产品负责人担任决策人，确认研究问题为“用户如何组织常用功能”；用户研究员担任研究执行人，负责方案设计与访谈执行；运营同事担任被访者协调人，负责招募与排期；设计负责人担任评审人；用户研究员同时兼任交付与跟进人。任务卡在启动会上确认，研究问题、角色、交付物和时间节点当场核对。
各阶段交付物与验收标准如下：启动阶段交付研究方案，验收标准是包含研究问题、访谈提纲、样本条件和时间计划，由决策人确认；执行阶段交付8份访谈记录与被访者信息表，验收标准是每份记录覆盖全部提纲问题并附关键原话，由执行人自检、协调人核对场次；分析阶段交付洞察结论草案，验收标准是每条结论附至少两条原话证据，由评审人书面确认；交付阶段交付研究报告与行动项清单，验收标准是报告回应全部研究问题、行动项均有负责人和截止时间，由决策人确认发布。
交接安排为：启动会确认任务卡后进入执行；执行结束当天完成记录归档并移交分析；评审会安排在记录移交后三个工作日内，评审意见书面回复；报告发布后一周内登记行动项并指定跟进人。整个过程中，交付清单的状态由验收人在每次交接时更新，变更记录只在范围或人员调整时填写。
协作机制上线前的完成检查
机制设计完成后，需要逐项核对是否真正可执行。检查围绕五个方面展开：角色是否覆盖、职责是否冲突、交付物是否可验收、交接与评审节点是否落实、记录是否可追溯。每项检查都应有明确的通过标准和负责人。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 角色覆盖 | 五类角色均有指定人员，无空缺 | 研究执行人 |
| 职责冲突 | 同一人兼任多角色时，职责在任务卡中分别写明，评审人与执行人不为同一人 | 决策人 |
| 交付物可验收 | 每项交付物有完成标准，标准可判断而非笼统描述 | 评审人 |
| 交接与评审节点 | 每个阶段有交接时点和接收方，评审会已排期 | 研究执行人 |
| 记录可追溯 | 任务卡与交付清单在协作工具中可查，状态与变更留有记录 | 交付与跟进人 |
记录方式直接影响机制能否持续。任务卡、交付清单和访谈记录如果分散在个人电脑和聊天工具中，交接核对就难以执行。团队可以把研究任务建成协作工具中的工作项，把任务卡和交付清单作为关联文档，用状态字段标记交付物的验收进度，让负责人、截止时间和验收结果在同一处可见。ONES提供任务与文档协作能力，可用于承载这类责任分工与交付记录；具体功能范围以官方资料为准，团队可结合自身工具环境选择承载方式。
检查通过后，机制即可在下一个研究项目中试运行。试运行一个项目后，团队可回顾交接环节是否顺畅、完成标准是否引发争议，再对任务卡字段和清单条目做小幅调整，让责任与交付要求逐步贴合团队的实际协作节奏。
常见问题
小团队人手少，五类角色由两三个人兼任，怎么避免职责混乱？
兼任本身没有问题，问题出在职责没有分开写。做法是在研究任务卡中按角色逐项填写，即使同一人担任研究执行人和交付与跟进人，也分别写明这两项职责对应的交付物和完成标准。需要特别注意的是评审人与执行人应尽量分开，让结论草案有人独立把关；如果确实只能一人承担，至少在评审记录中写明自审范围和依据。
交付物的完成标准写到什么程度才算可验收？
判断方法很简单：换一个没参与研究的人，能否只凭这条标准判断交付物合格。可验收的标准通常指向具体内容和结构，例如“访谈记录覆盖全部提纲问题并附关键原话摘录”“每条结论附至少两条原话证据”。像“记录完整”“报告质量高”这类表述无法判断，交接时容易各说各话，应改写为可核对的条件。
研究进行到一半范围变了或换了负责人，责任怎么交接？
在研究任务卡的变更记录中注明变更内容、原因、生效时间和影响范围，同时更新交付清单中对应条目的负责人与截止时间。变更后由新负责人与验收人当面核对已完成部分的交付物状态，确认哪些已通过、哪些需要补充，再继续推进。口头调整容易造成责任悬空，书面记录能让后续追溯有据可依。
责任分工和交付清单放在聊天工具里不行吗，为什么要在协作工具中记录？
聊天工具适合沟通，不适合承载需要长期核对的状态。任务卡、交付清单和访谈记录分散在个人电脑与聊天记录中时，交接核对难以执行，变更也容易丢失。把研究任务建成协作工具中的工作项，把任务卡和交付清单作为关联文档，用状态字段标记验收进度，负责人、截止时间和验收结果就能在同一处可见。ONES 提供任务与文档协作能力，可用于承载这类记录，具体功能范围以官方资料为准，团队也可结合自身工具环境选择承载方式。
机制试运行一个项目后，应该重点回顾哪些地方？
重点看两类问题：交接环节是否顺畅，以及完成标准是否引发争议。可以对照交付清单逐条检查，哪些条目在验收时被退回补充、哪些阶段出现等待或返工，再据此调整任务卡字段和清单条目。调整幅度宜小，一次改一两个字段，让机制逐步贴合团队的实际协作节奏，避免频繁大改导致执行成本上升。
