用户研究的落地路径可以概括为：先把模糊的业务疑问收敛成可回答的研究问题，再选择匹配的方法组合，按招募、执行、分析、交付四步推进，最后把洞察转成可跟踪的产品决策与验证动作。本文按这一顺序给出每一步的输入、动作、负责人和产出物，并附一份端到端示例与完成检查清单，帮助产品经理或研究新人建立一套能重复执行的流程。研究结论要进入需求评审与版本规划，通常需要在工作项与文档之间保持可追溯，ONES 可作为承载这类流转的管理方向。
要点总览（TL;DR）
- 用户研究从收敛研究问题开始：把业务目标、现有数据和待决策点放在一起，写成能被证据回答的问题与可验证假设，再进入方法选择。
- 方法按问题类型组合：访谈回答动机与情境，可用性测试观察任务阻碍，问卷量化分布，日志数据还原真实路径；定性先行、定量验证是常见顺序。
- 执行阶段的质量取决于样本筛选、脚本版本和原始记录留存，招募表、录屏录音与执行日志要统一归档，偏差当场记录。
- 分析时先编码再归纳，主动处理反例，结论按证据强度分级，并把事实、解释与建议分开表述。
- 洞察要转成带来源、证据级别和跟踪指标的需求条目，进入评审与版本规划，上线后回到原结论核对是否成立。
先定研究问题：把业务疑问转成可回答的假设
用户研究的第一步是把业务方的疑问写成可以被证据回答的研究问题。跳过这一步直接选方法，常见结果是访谈做完了，却说不清结论支持哪个决策。研究问题与业务问题的区别在于：业务问题描述“我们想达成什么”，例如“新用户为什么在第三天流失”；研究问题描述“我们需要观察或测量什么才能判断”，例如“新用户在首次完成核心任务时，遇到哪些阻碍，这些阻碍与放弃使用之间是什么关系”。
问题收敛需要三类输入：业务目标（本季度要改善的指标或要做的决策）、现有数据（埋点、工单、客服记录、已有报告能说明什么、还缺什么）、待决策点（这次研究结束后，谁要做什么决定）。把三者放在一起，才能判断哪些疑问已有答案、哪些必须通过新研究补齐。
假设的写法建议包含对象、情境、预期和行为依据，常用结构是“我们预期［某类用户］在［某情境］下会［某行为或态度］，因为［现有线索］”。假设的作用是让研究有验证方向，同时允许被推翻。每条假设应能对应到至少一种可采集的证据。
产出形式是一份可评审的研究问题与假设清单，建议包含以下字段：
- 业务目标与对应决策点，写明决策人和决策时间；
- 研究问题，每条写成可被证据回答的问句；
- 对应假设与现有线索来源；
- 优先级，按对决策的影响程度排序；
- 不在本次范围内的疑问，明确排除以免范围蔓延。
这份清单的完成标志是：业务方与研究者对“研究结束后要回答什么”达成一致，并且每条问题都能指向一个具体决策。
按决策需要选择研究方法组合
方法选择的依据是问题类型、决策时点和样本可得性，而非方法的新旧。要回答“为什么”和“在什么情境下发生”，优先用访谈、情境观察等定性方法；要回答“任务能否完成、卡在哪里”，用可用性测试；要回答“有多少人、优先级如何”，用问卷等定量方法；要还原真实使用路径和规模，用日志或行为数据分析。决策时点越近，越应选择周期短、能快速给出方向的方法；样本难以触达时，行为数据往往比招募访谈更可行。
| 方法 | 适合回答的问题 | 典型产出 | 使用条件 |
|---|---|---|---|
| 深度访谈 | 动机、决策过程、使用情境、痛点成因 | 访谈记录、主题归纳 | 能接触到目标用户，问题偏探索性 |
| 可用性测试 | 任务能否完成、界面阻碍、操作误解 | 任务完成情况、问题清单 | 有可交互原型或已上线版本 |
| 问卷 | 分布、比例、优先级排序、满意度 | 统计数据、交叉分析 | 问题已较明确，需要量化范围 |
| 日志与行为数据分析 | 真实路径、流失节点、功能使用分布 | 行为漏斗、路径分析 | 埋点完整，数据口径清晰 |
定性先行、定量验证是常见组合顺序：先用少量访谈形成对问题和原因的假设，再用问卷或行为数据确认范围与强度。反过来也成立，当数据先暴露出异常，再用访谈解释原因。组合时要写清每种方法回答清单中的哪几条问题，避免重复采集同一证据。
方法选择容易出现几类偏差：用问卷回答“为什么”，得到的是用户自述的原因而非真实成因；样本只覆盖活跃用户，结论却推广到全部用户；只做定性就下规模结论；把可用性测试当成需求优先级调研。规避方式是在方案里标注每种方法的结论适用范围，并说明哪些结论需要后续验证。
产出是一张方法与样本方案对照表，逐条列出研究问题、对应方法、样本条件、执行周期和预期产出，作为评审和排期的依据。
招募与执行：样本、脚本与过程记录
执行阶段的质量决定后续分析是否可信。招募先写筛选条件：用户类型、使用阶段、关键行为特征、排除条件（如内部人员、近期参加过同类研究）。筛选条件应与研究问题直接对应，例如研究新用户流失，就需要覆盖留存与流失两类用户，而非只找活跃用户。招募渠道可以是产品内邀请、客服工单回访、用户社群或第三方样本服务，渠道不同会影响样本偏差，需在记录中注明。
访谈或测试脚本按“暖场—背景—核心任务或问题—追问—收尾”组织。核心部分要围绕研究问题设计开放式问题，避免诱导性提问；可用性测试则给出任务描述而不提示操作路径，观察用户实际行为。脚本应标注版本号，执行中修改需记录原因。
过程记录建议保留：招募筛选表（含入选与未入选原因）、脚本版本、知情同意记录、访谈录音或测试录屏、现场笔记、执行日志（时间、参与人、异常情况）。原始材料按统一命名归档，便于分析阶段回溯。
常见执行偏差及纠正：
- 主持人追问过多导致引导，纠正方式是提前标注必问与可选追问，复盘时检查提问中性度；
- 样本集中在易触达人群，纠正方式是设置配额并在招募表中核对；
- 记录只留结论不留原话，纠正方式是现场记录关键原话与情境；
- 测试环境与真实环境差异过大，纠正方式是在报告中说明环境条件及其影响。
本阶段的完成标志是：计划样本全部完成或达到信息饱和，原始材料完整归档，执行中的偏差已有记录。
从原始材料到洞察：编码、归纳与结论分级
分析从整理开始：把录音转写或笔记按参与者编号，去除无关内容但保留原话。编码是把材料中与研究问题相关的片段打上标签，标签可以来自研究问题，也可以在执行中新增。建议先对少量材料做开放编码，形成初始标签表，再统一应用到全部材料，避免前后标准不一致。
归纳是在编码基础上找模式：哪些标签反复出现、出现在哪类用户身上、在什么情境下出现。同时要主动处理反例，记录与主模式不一致的案例及其可能原因，反例往往能界定结论的适用边界。模式形成后，回到研究问题逐条回答，说明证据来自哪些参与者、强度如何。
结论建议做可信度分级，便于决策者判断使用方式：
| 级别 | 证据条件 | 建议用法 |
|---|---|---|
| 较强 | 多类用户重复出现，且有行为数据或多种方法相互印证 | 可直接支撑方案决策 |
| 中等 | 在特定用户群中稳定出现，证据来源单一 | 支撑方向判断，需补充验证 |
| 待验证 | 个别案例或探索性发现 | 作为假设进入后续研究或小范围试验 |
写作时区分事实、解释与建议：事实是“8 名参与者中有 6 名在第二步放弃”，解释是“可能因为第二步要求填写的信息与当前任务无关”，建议是“评估精简第二步字段”。三者分开写，读者才能判断结论的证据基础。
产出是编码表与分析结论稿，结论稿按研究问题组织，每条结论标注证据级别、适用用户范围和对应建议。
角色分工与各阶段交付物
研究流程要能重复运行，需要明确谁在什么节点交付什么。以下分工是参考框架，团队规模较小时可由一人承担多个角色，但交接物仍应保留。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 产品经理 | 提出业务问题与决策点，确认研究范围，承接结论进入需求 | 研究需求说明、决策点清单、需求池条目 |
| 研究者 | 收敛研究问题、设计方案、执行与分析、交付结论 | 研究问题与假设清单、方法方案、编码表、结论稿 |
| 设计师 | 提供测试原型与任务场景，参与可用性测试观察 | 测试用原型、任务脚本输入、问题清单反馈 |
| 数据角色 | 提供行为数据、核对口径、协助样本筛选与结论验证 | 数据提取说明、样本名单、验证指标 |
评审节点建议设在三处：研究问题与方案评审（确认问题可回答、方法匹配）、执行中期检查（样本与记录是否符合计划）、结论评审（证据是否支撑结论、建议是否可执行）。研究需求受理可采用统一入口，写明业务问题、决策点、期望时间，由研究者评估排期并反馈，避免口头需求插队导致质量下降。
洞察进入需求池需要交接规则：每条建议对应一个需求条目，写明来源研究、证据级别、适用用户范围、建议的验证方式与跟踪指标。这样需求评审时能追溯依据，版本上线后也能回到原结论核对是否成立。研究文档、结论与需求条目在同一协作平台中关联，可以减少结论停留在报告里的情况，ONES 支持工作项与文档的关联管理，可作为这类流转的承载方式。
示例：一次新功能上线前的用户研究流程
以下为演示情景，用于说明各步骤如何衔接，不代表真实项目数据。
情景设定。某协作工具计划上线“批量任务导入”功能，业务方担心新用户不理解导入模板而放弃使用。决策点是：是否在首版加入模板引导，以及引导放在哪个环节。研究问题收敛为：新用户在准备导入文件时遇到哪些阻碍；模板说明放在哪一步能减少失败重试。假设为“首次使用的用户在下载模板后，因字段含义不清而反复修改，预期在模板旁提供字段示例可减少重试”。
方法与样本。先用 6 名近期注册且尝试过导入的用户做任务测试，观察准备文件与上传过程；同步提取导入失败与重试的行为数据，确认失败集中在哪些步骤。样本覆盖成功与失败两类用户，测试使用可交互原型。
执行与分析。测试按任务脚本进行，记录操作路径、停顿点与原话，保留录屏。分析时对阻碍点编码，归纳出“字段含义不清”“示例文件与自身数据结构不一致”两类模式，并用行为数据核对失败步骤的分布。结论标注证据级别：字段含义问题有多名参与者与数据印证，列为较强；示例文件问题证据来源单一，列为中等。
进入版本决策。结论评审后形成两条需求：在模板下载处增加字段示例，在导入页增加失败原因提示。每条需求关联研究结论与跟踪指标（导入成功率、重试次数），进入版本规划；上线后按指标核对结论是否成立，未成立的部分回到研究清单继续验证。
完成检查：研究质量与落地效果的自查项
研究收尾时按以下清单逐项核对，任一项不通过都应补充或说明原因。
- 研究问题与决策点对应：每条研究问题都能指向一个决策人和决策时间；清单中已排除的疑问有明确记录。
- 方法与问题匹配：每种方法都标注了回答哪条问题及结论适用范围；定性与定量的组合顺序有说明。
- 样本与执行合规：筛选条件与配额已核对；知情同意、录音录屏与原始材料完整归档；执行偏差有记录。
- 结论与证据对应：每条结论标注证据来源、参与者范围与可信度级别；事实、解释、建议分开表述；反例已处理。
- 落地与跟踪：建议已转为需求条目并关联研究结论；每条需求写明验证方式与跟踪指标；上线后有核对结论的时间点。
- 可复用性：研究问题清单、脚本、编码表与结论稿已归档，可供后续同类研究参考。
这份清单同时用于判断研究是否完成：问题可回答、证据可追溯、结论能进入决策并有后续验证安排，四项同时满足，研究才算真正落地。
常见问题
团队规模小、没有专职研究者，用户研究还能怎么做？
可以由产品经理承担研究者的职责，但建议保留三个关键交接物：研究问题与假设清单、方法方案、结论稿。执行时把访谈与可用性测试合并安排，一次招募覆盖多个问题；分析阶段请设计师或数据角色参与编码复核，减少单人判断偏差。角色合并后，评审节点仍要保留，至少在研究方案和结论两处让决策人确认。
研究做到一半发现原定问题问不出结论，应该调整还是继续？
先判断是问题本身不可回答，还是方法或样本不匹配。如果是问题过于宽泛，回到研究问题清单收窄范围，并同步告知决策人调整后的范围；如果是样本偏差导致证据不足，补充配额或增加一种方法交叉验证。调整需在执行日志中记录原因和时间点，结论稿中说明哪些问题未得到回答、需要后续研究补齐，避免把未验证的部分写成结论。
定性访谈的结论能不能直接用来定需求优先级？
定性访谈适合解释原因和发现情境，用来判断优先级时需要补充范围信息。常见做法是先用访谈形成问题分类与假设，再用问卷或行为数据确认各类问题的影响面，最后结合业务目标排序。如果时间不允许补充定量，应在结论中标注证据级别为中等或待验证，并把优先级决策与后续验证动作绑定，例如先小范围上线观察指标。
研究结论进入需求池后，怎么判断它是否真的被用上了？
在需求条目上写明来源研究、证据级别、适用用户范围和跟踪指标，版本上线后按指标核对结论是否成立。核对结果分三种处理：指标支持结论则关闭该研究问题；指标不支持则回到研究清单补充验证；指标无法判断则检查埋点或指标口径是否可用。定期回看已关闭的研究问题与对应需求，能看出研究对决策的实际影响。
用户研究涉及用户录音和个人信息，执行时要注意什么？
招募时说明研究目的、记录方式和材料用途，取得知情同意后再录音录屏；原始材料按参与者编号存储，限制访问范围，报告中引用原话时做匿名处理。跨团队共享时优先提供脱敏后的结论稿与编码表，原始记录按团队的数据管理要求保存和清理。具体合规要求以所在组织的制度为准。
