用户研究要落到可执行层面，关键是把它当成一条从决策出发、再回到决策的闭环：先明确要支持什么产品决策，再选择匹配的方法，按招募、执行、记录、分析、输出洞察、落地验证推进。本文按这条主线拆解每一步的输入、动作、交付物和完成标志，适合产品经理或研究员从零启动一次研究时对照使用。
要点总览（TL;DR）
- 用户研究从产品决策倒推研究问题：写清决策背景、备选方案依赖的假设和成功标准，避免把“了解用户”当目标。
- 方法按问题类型选：访谈与观察回答动机和行为过程，问卷回答分布与规模，可用性测试回答任务能否完成；定性与定量常组合使用。
- 执行按招募、访谈或测试、记录整理、编码分析推进，每一步保留输入、输出和可追溯的用户原话与情境。
- 分析阶段先归纳主题与模式，再区分洞察（用户事实与原因）和建议（产品动作），每条建议对应到洞察，决策才有依据。
- 收尾用检查清单核对问题与决策对应、样本与方法匹配、洞察可追溯、建议有承接人，四项通过才算形成闭环。
先定研究问题：从产品决策倒推研究目标
用户研究常见的失败起点是“我们想了解一下用户”，这类目标无法判断研究是否完成。更有效的做法是先写清这次研究要支持哪个产品决策，再倒推研究问题。决策越具体，研究问题越容易收敛。
把业务疑问转化为研究问题，可以按四步走：
- 写清决策背景：当前面临什么选择，例如“新功能是否值得投入开发”“现有流程的改版方向选A还是B”。
- 列出备选方案与风险：每个方案成立依赖什么用户假设，假设不成立会带来什么代价。
- 把假设转成可回答的问题：将“用户应该会喜欢”改写为“目标用户在完成某任务时，遇到的主要阻碍是什么，这些阻碍是否影响其继续使用”。
- 设定成功标准：明确什么样的证据足以支持决策，例如“多数目标用户在同一环节受阻”或“两类用户对方案偏好存在明显差异”。
研究目标说明书建议包含以下字段，作为后续方法选择和执行的依据：
| 字段 | 填写要求 |
|---|---|
| 决策背景 | 要做什么决策、时间节点、决策人 |
| 研究问题 | 1—3个可回答的问题，避免笼统的“了解用户” |
| 关键假设 | 每个备选方案依赖的用户假设 |
| 目标用户 | 与研究问题直接相关的用户类型与特征 |
| 成功标准 | 什么证据出现即可支撑决策 |
| 范围与限制 | 时间、预算、可触达的用户范围 |
完成标志是：团队能就“这次研究回答什么问题、不回答什么问题”达成一致，且每个研究问题都能对应到一个具体决策。
选对方法：访谈、观察、问卷与可用性测试的适用场景
方法选择服从研究问题。定性方法回答“为什么、怎么做”，适合挖掘动机、行为过程和阻碍；定量方法回答“有多少、多普遍”，适合验证规模与分布。两者常组合使用：先用定性方法发现模式和假设，再用定量方法验证范围。
| 方法 | 适合回答的问题 | 典型产出 | 使用条件 |
|---|---|---|---|
| 深度访谈 | 用户为什么这样操作、需求和动机是什么 | 行为故事、动机与痛点描述 | 能接触到目标用户，问题偏探索性 |
| 现场观察 | 用户在真实环境中如何完成任务、有哪些未言明的习惯 | 行为流程记录、环境约束 | 使用场景对结果影响大，可进入现场 |
| 问卷 | 某类现象有多普遍、不同群体的分布差异 | 比例、分布、相关性数据 | 问题已较明确，样本可规模化触达 |
| 可用性测试 | 用户能否顺利完成指定任务、卡在哪里 | 任务完成率、受阻点、操作录像 | 已有原型或可操作界面 |
样本量与招募条件同样服从研究问题。定性研究重在覆盖关键用户类型和极端情形，样本以“是否出现新信息”为判断依据，达到信息饱和即可；定量研究需考虑抽样代表性和统计精度，样本规模应结合决策风险确定。招募条件应写清用户类型、使用频率、关键行为特征和排除条件，避免把“方便找到的人”当成目标用户。
完成标志是：每个研究问题都能对应到一种主方法和必要的辅助方法，招募条件清单可直接用于筛选候选人。
执行流程：招募、执行、记录与分析的操作步骤
执行阶段按时间顺序推进，每一步都有明确输入和输出。
招募用户
输入是招募条件清单。渠道可从现有用户库、客服与销售反馈、社群、第三方招募平台中选取，优先选择能触达目标用户类型的渠道。筛选时用简短问卷核对关键条件，并排除与研究问题无关的干扰样本。输出是一份确认时间、形式与知情同意的参与者名单。
执行访谈与测试
输入是访谈或测试脚本。脚本围绕研究问题设计，访谈以开放式问题为主，先问行为再问原因；可用性测试给出具体任务，主持时保持中立，不引导答案，遇到用户卡住先观察再追问。输出是录音、录像或现场笔记。
记录与整理
输入是原始录音和笔记。执行后尽快转写或整理要点，保留用户原话和关键行为片段，标注时间、用户编号和情境。输出是结构化的原始记录表，字段可包括用户编号、场景、行为、原话、初步标注。
编码分析
输入是整理后的记录。先做开放式编码，给每段有意义的记录打上简短标签；再合并相近标签形成主题；最后统计各主题出现的用户数和情境。输出是编码表与主题清单，作为下一阶段提炼洞察的基础。
完成标志是：原始记录可追溯到具体用户和情境，编码表能支撑主题归纳，且分析过程可被他人复核。
从原始记录到可落地洞察：分析与输出
分析的目标是把零散记录归纳为结构化洞察，并转化为产品可用的结论。提炼主题与模式可按三步进行：先按研究问题归类编码，再找出跨用户重复出现的模式，最后解释模式背后的原因和影响。
需要区分洞察与建议。洞察描述用户事实与原因，例如“新用户在首次配置环节反复返回上一步，主要因为不清楚必填项含义”；建议是产品动作，例如“在配置页增加字段说明”。把建议当结论，会让研究失去可验证性；先写清洞察，再基于洞察提出建议，决策才有依据。
研究报告或洞察文档建议包含以下结构：
- 研究背景与问题：决策背景、研究问题、方法与样本说明
- 核心洞察：按主题组织的用户事实、原因与影响范围
- 证据引用：每条洞察对应的用户原话或行为记录
- 建议与优先级：对应到具体产品动作，标注依据和不确定性
- 局限与后续验证：样本限制、待验证假设
完成标志是：每条洞察都能追溯到原始记录，每条建议都能对应到洞察，且决策人能据此判断下一步动作。
角色分工与交付物：谁来做、产出什么
角色划分可按研究员、产品经理、设计师、数据分析师进行，小团队可兼任，关键是每个交付物都有明确负责人和评审人。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 产品经理 | 提出决策背景，确认研究问题与成功标准，推动结论落地 | 研究目标说明书、决策记录 |
| 研究员 | 设计方法与脚本，执行访谈与测试，主导分析与报告 | 研究方案、脚本、编码表、研究报告 |
| 设计师 | 提供原型与测试材料，参与观察和洞察评审 | 测试用原型、设计建议 |
| 数据分析师 | 提供行为数据，设计问卷抽样与统计分析 | 数据摘要、问卷统计结果 |
各阶段交付物可归纳为：研究目标说明书、方法选择与招募清单、执行脚本与记录模板、编码表与主题清单、洞察报告、落地跟踪记录。跨角色评审建议在研究问题确定后和执行结束后各安排一次，前者确认方向，后者确认结论与后续动作；交接时以文档和工作项为载体，确保建议有人承接。
当研究问题、洞察和建议需要在团队间持续流转时，可以把它们作为可追踪的工作项和文档管理起来。ONES 支持将需求、任务与文档关联到同一项目空间，便于把研究结论对应到具体产品动作并跟踪状态；具体配置方式可按团队现有流程安排。
示例：一次新产品功能验证研究的完整过程
以下为演示情景，用于说明流程如何串联。
某团队计划为协作工具新增“任务模板”功能，需要决定是否投入开发以及首版包含哪些模板类型。决策背景是版本排期临近，备选方案为“全量开发”和“先做高频场景”。研究问题定为：目标用户在创建重复性任务时，现有方式的主要阻碍是什么；哪些任务类型最需要模板。
方法上选择定性访谈加可用性测试：先访谈经常创建重复任务的用户，了解现有做法和阻碍；再用低保真原型测试模板创建流程，观察用户能否顺利完成。招募条件为近一个月内每周创建任务超过一定频次的活跃用户，覆盖不同职能角色。
执行阶段按脚本完成访谈和测试，记录用户原话与操作过程，整理为原始记录表并编码。分析后发现：用户反复手动复制旧任务，主要因为不清楚如何复用；测试中多数用户在模板选择环节停留较久，原因是分类命名与自身任务类型对不上。
洞察输出为两条：重复任务依赖手动复制，反映复用入口不明显；模板分类与用户心智不匹配，影响选择效率。对应建议为优化复用入口、按用户任务类型重命名分类。团队据此调整首版范围，并把建议转为待办工作项跟踪落地。
完成检查：判断研究是否做到位的核对项
研究收尾时可用以下清单逐项核对，判断研究是否完成、结论是否可信。
| 检查维度 | 核对项 | 通过标准 |
|---|---|---|
| 问题与决策对应 | 每个研究问题是否对应具体决策；成功标准是否事先写明 | 决策人能指出研究支持了哪个选择 |
| 样本与方法匹配 | 方法是否匹配问题类型；样本是否覆盖目标用户类型；招募条件是否执行 | 方法与问题一致，样本局限已说明 |
| 洞察可追溯 | 每条洞察是否有原始记录支撑；洞察与建议是否区分 | 可随机抽取洞察回溯到用户记录 |
| 落地跟踪 | 建议是否转为具体动作并有负责人；后续验证是否安排 | 建议有承接人和状态，待验证假设有跟进计划 |
四项均通过，说明这次研究形成了从问题到洞察再到决策的闭环；若某项不通过，应补充证据或明确标注局限，再进入下一轮研究。
常见问题
团队规模小、没有专职研究员，用户研究还能怎么做？
可以按角色兼任的方式推进，关键是每个交付物有明确负责人和评审人。产品经理负责写清决策背景与研究问题，设计师提供原型并参与观察，数据分析师支持问卷抽样与行为数据，访谈执行可由产品经理或设计师承担。小团队更需要控制研究范围：一次只回答1—3个与当前决策直接相关的问题，样本以覆盖关键用户类型为准，达到信息饱和即可停止招募。评审安排在研究问题确定后和执行结束后各一次，前者确认方向，后者确认结论与后续动作。
定性访谈做多少场才够，样本量怎么定？
定性研究不以固定数字为准，而以是否出现新信息为判断依据：当后续访谈不再带来新的主题或阻碍点时，可认为达到信息饱和。实际操作中，先按用户类型和关键行为特征划分几类目标用户，确保每类都有覆盖，并主动纳入极端或边缘情形。定量研究则需考虑抽样代表性和统计精度，样本规模结合决策风险确定，风险越高越需要更充分的样本。无论哪种方法，招募条件都应事先写清并执行，避免把方便找到的人当成目标用户。
研究结论和产品经理的直觉冲突时，应该听谁的？
先回到证据本身：检查每条洞察能否追溯到具体用户记录，样本是否覆盖了决策涉及的用户类型，研究问题是否与当前决策对应。如果证据充分且样本匹配，应以研究结论作为讨论基础；如果样本存在明显局限，应把冲突点标注为待验证假设，安排补充研究或小范围验证，而不是直接否定任何一方。把洞察与建议分开写也有助于处理冲突：洞察描述用户事实与原因，建议是产品动作，团队可以对建议有不同选择，但对事实应有共同认知。
研究做完了，建议怎么跟进才不会不了了之？
在报告交付时就把建议转成具体动作：每条建议写明对应洞察、负责角色和下一步状态，纳入团队日常的任务或需求管理流程中跟踪。安排一次结论评审，由决策人确认采纳哪些建议、暂缓哪些、哪些需要补充验证。后续验证可以设定观察指标或安排小范围回访，把验证结果回写到原洞察记录中。这样研究结论与产品动作之间保持可追溯的对应关系，也便于下一轮研究复用。
已有行为数据，还需要做访谈吗？
两者回答的问题不同。行为数据能说明发生了什么、在哪些环节流失或停留，但难以解释用户为什么这样操作、当时的判断依据是什么。访谈和观察适合补充动机、理解与环境约束，帮助解释数据背后的原因。常见做法是先用行为数据定位异常环节或高频路径，再针对这些环节设计访谈问题，用少量深度访谈解释原因，最后用问卷或数据验证范围。这样组合能减少盲目访谈，也让数据结论更有解释力。
