用户访谈的价值取决于它是否服务于一个明确的产品决策。开始之前先确定要回答的问题、找谁访谈、验证哪些假设，再按半结构化提纲执行，把每场记录整理成可追溯的洞察，并转化为可验证的需求或假设。本文按访谈前、提纲设计、招募执行、编码交付、角色分工、完整示例和质量自查七个环节展开，适合产品经理、设计师和用户研究人员独立组织一轮访谈时使用。
要点总览（TL;DR）
- 访谈目标来自具体产品决策：先写清决策问题、受访者画像和3–5条可检验假设，再开始招募。
- 提纲按暖场、行为回溯、痛点与替代方案、期望与优先级、收尾五段组织，以过去真实行为提问，主问题控制在8–12个。
- 招募用统一筛选问题确认画像，单场45–60分钟，主持人负责提问、记录人保留原话与行为，当天完成记录整理。
- 记录按行为、动机、阻碍、替代方案编码，洞察写成现象—影响—证据出处，并转化为可验证的需求候选条目。
- 用自查清单核对目标、样本覆盖、提纲质量、记录完整性和洞察证据，出现关键类型缺失或单一证据支撑时安排补充访谈。
访谈前先定清楚：要回答什么产品问题
访谈目标来自具体的产品决策，常见的有四类：需求取舍（下一版做哪个功能）、流程改版（现有路径哪里卡住）、新功能验证（用户是否会采用）、流失或低活跃原因排查。先写下这次访谈要支撑的决策，再倒推需要什么信息。如果决策问题写不出来，说明访谈时机未到，先做数据分析或可用性测试更合适。
目标受访者按四个维度界定：角色（如管理员、一线操作者、审批人）、使用频次（高频、低频、已流失）、使用场景（在什么任务中用到产品）、使用阶段（新用户、稳定使用、准备迁移）。维度越具体，招募筛选越容易执行。例如“近三个月内每周至少使用两次报销审批功能、且经历过一次审批退回的财务人员”，比“财务用户”更能指导招募。
把待验证假设写成可被访谈检验的陈述，而不是笼统的疑问。可检验的写法通常包含对象、行为和预期原因，例如“新用户在前三次使用时因为找不到批量导入入口而放弃导入”。访谈中通过行为回溯确认或推翻这类陈述，而不是直接问用户“你是不是因为找不到入口”。
同时明确本次访谈不解决的问题，例如不讨论定价、不评估竞品、不做整体满意度调研。范围外事项写进任务说明，遇到受访者主动提起时记录但不展开追问，避免单场访谈发散。
本环节的交付物是一页访谈任务说明，包含：决策问题一句话、受访者画像四个维度、3–5条待验证假设、范围外事项清单。这一页在招募前完成，并由需求方确认。
半结构化提纲怎么设计：问题顺序与追问方式
半结构化提纲的作用是保证覆盖关键话题，同时留出追问空间。提纲按五段组织，每段承担不同任务：
- 暖场与背景：确认受访者身份、日常工作内容、与产品相关的使用情况，建立对话氛围，约5分钟。
- 具体行为回溯：请受访者回忆最近一次完成相关任务的过程，按时间顺序讲清楚做了什么、用了什么工具、遇到什么。这是提纲的主体，约15–20分钟。
- 痛点与替代方案：围绕回溯中出现的中断、绕行、手工补救追问原因，以及当时用了什么替代办法，约10分钟。
- 期望与优先级：询问受访者对改进方向的看法和取舍，注意区分真实需求与随口建议，约5–8分钟。
- 收尾：补充遗漏问题、确认是否可后续回访、致谢，约3分钟。
提问以过去真实行为为主，减少假设性提问。“如果有一个功能能自动完成，你会用吗”这类问题得到的答案参考价值有限；换成“上一次做这件事时，你花了多长时间、具体步骤是什么”，得到的是可核对的事实。引导性措辞也要避免，例如“你是不是觉得这个流程很麻烦”，改为“这个流程你当时是怎么走的”。
追问使用固定句式，降低现场组织语言的负担：
- “请举一个最近的例子。”
- “当时你具体怎么做的？”
- “后来呢？结果怎么样？”
- “为什么这样处理，当时是怎么考虑的？”
提纲控制在8–12个主问题，每个主问题预留2–3个追问方向。问题写成开放句，避免是非题；把问卷式的选项题留在问卷里，访谈现场只保留需要展开叙述的问题。提纲完成后做一次内部试访，检查问题是否诱导、时间是否够用。
招募、执行与记录：一场访谈的完整操作
招募从筛选问题开始。筛选问题要能直接判断受访者是否符合画像，例如使用频次、最近一次使用时间、是否经历过特定流程。渠道可以来自产品内的用户名单、客服工单记录、社群或既有用户库；无论渠道如何，都用同一组筛选问题确认资格，并记录筛选结果。样本要覆盖画像中的关键类型，单一类型受访者过多时，结论容易偏向某一类使用方式。
访谈形式按受访者便利选择线上或线下，单场控制在45–60分钟。开始前说明访谈目的、录音用途和匿名处理方式，取得明确同意后再录音；受访者不同意录音时，由记录人做详细笔记。线上访谈提前测试设备，线下选择安静、不受打扰的场所。
一场访谈通常由主持人、记录人两个角色配合。主持人负责提问、追问和控场，记录人负责记录原话、标注时间点和观察到的行为，并在主持人遗漏追问时通过约定信号提醒。只有一人时，优先保证记录完整，可减少追问深度。
单场访谈记录表至少包含以下字段：
| 字段 | 填写要求 |
|---|---|
| 访谈时间与形式 | 日期、时长、线上或线下 |
| 受访者编号 | 匿名编号，与招募筛选记录对应 |
| 画像信息 | 角色、使用频次、使用阶段 |
| 原话摘录 | 关键表述逐字记录，标注大致时间点 |
| 观察到的行为 | 操作路径、停顿、绕行、替代工具 |
| 待跟进问题 | 现场未展开、需要回访确认的点 |
访谈结束当天完成记录整理：补齐录音中的原话、核对编号、把待跟进问题单独列出。当天整理能保留现场记忆，避免多场访谈后记录混淆。整理完成的记录进入统一存放位置，供后续编码使用。
从记录到洞察：编码、归纳与交付
编码是把原始记录转成可比较标签的过程。逐条阅读记录，把每个有信息量的片段打上标签，标签按四类归组：行为（用户实际做了什么）、动机（为什么这样做）、阻碍（在哪里卡住、绕行）、替代方案（用了什么别的办法）。标签用简短动宾短语，例如“手工导出后二次整理”“审批退回后电话确认”。同一片段可以打多个标签，但每个标签要能回溯到具体记录和受访者编号。
多场访谈完成后做合并统计。把相同或相近的标签归并为模式，记录出现的受访者数量和类型分布。出现在多数受访者中、且跨越不同画像类型的模式，可以作为共性洞察；只出现在个别人身上的观点标注为个别情况，不直接升级为需求依据。频次统计的作用是区分证据强度，不是简单投票。
洞察陈述按“现象—影响—证据出处”三段写。例如：“审批退回后，用户普遍通过电话或即时消息确认原因（现象），导致单次审批平均多出一次沟通往返（影响），证据见受访者03、05、07的记录摘录（出处）。”这样的写法让结论可核对，也方便后续评审时质疑和补充。
输出物通常包括三份：洞察清单（每条含现象、影响、证据出处、覆盖受访者数量）、用户旅程或场景地图（把行为和阻碍按任务阶段排列）、需求候选条目（把洞察转成可验证的产品假设或需求描述，标注来源洞察编号）。需求候选条目写清要解决的问题和预期改变的行为，具体方案留到需求评审阶段讨论。
洞察与需求候选需要进入团队日常使用的文档和工作项中，才能被后续排期和评审引用。在ONES中，可以把洞察清单作为文档沉淀，把需求候选建为工作项并关联来源记录，使每条需求都能追溯到访谈证据；评审时按工作项状态推进，避免结论停留在个人笔记里。
角色分工与交付物对照
访谈各环节的职责需要提前分配，避免执行时互相等待。常见分工如下：
| 环节 | 主责角色 | 参与角色 | 交付物 |
|---|---|---|---|
| 目标设定 | 产品经理 | 研究者、设计师 | 访谈任务说明 |
| 提纲设计 | 研究者 | 产品经理、设计师 | 半结构化提纲 |
| 招募筛选 | 研究者 | 产品经理、客服或运营 | 受访者名单与筛选记录 |
| 访谈执行 | 主持人（研究者或设计师） | 记录人 | 录音与现场笔记 |
| 记录整理 | 记录人 | 主持人 | 单场访谈记录表 |
| 编码归纳 | 研究者 | 设计师、产品经理 | 洞察清单、场景地图 |
| 需求转化 | 产品经理 | 研究者 | 需求候选条目 |
跨角色评审安排在两个时点：提纲定稿前评审一次，确认问题覆盖决策问题且无明显诱导；洞察清单完成后评审一次，由产品经理和设计师核对结论是否有证据支撑、需求候选是否可验证。评审以文档形式留痕，修改意见对应到具体洞察编号。
一个完整示例：新功能上线前的用户访谈
以下为演示情景，用于说明各步骤如何衔接，不代表真实项目结论。
情景设定：某协作工具计划改版任务批量处理功能，访谈目标是确认现有批量操作在真实任务中的使用方式与中断点。受访者画像为：近一个月内每周至少使用两次批量操作的项目成员，覆盖管理员和普通成员两类角色，共招募6人。
提纲片段与追问：主问题“请回忆最近一次需要同时处理多个任务的经历，从开始到完成你做了哪些操作？”追问“当时为什么选择批量处理而不是逐个处理？”“中间有没有停下来的时候，当时在等什么？”“后来这个问题怎么解决的？”
记录摘录与编码：受访者02提到“选完十几个任务之后发现有一个选错了，只能全部取消重选”。编码为行为“全选后取消重选”、阻碍“批量选择无法局部调整”。受访者04提到“批量改完状态还要一个个补备注，干脆就只改状态”。编码为行为“拆分操作”、阻碍“批量操作覆盖字段不全”。
归纳洞察与需求候选：6名受访者中有4人提到批量选择后难以局部调整，2人提到批量操作字段覆盖不全。形成洞察“批量操作在选中后缺乏局部修正手段，用户倾向于取消重来或拆成多次操作”，需求候选为“支持批量选择后的单项移除与字段补充，验证指标为批量操作完成率和取消重选次数”。
适用边界：该示例适用于工具类产品的功能改版前访谈；面向复杂业务流程或强合规场景时，受访者画像和提纲需要增加流程与权限相关维度。可迁移的规律是：目标来自决策、假设写成可检验陈述、记录保留原话、洞察标注证据出处。
完成检查：访谈质量的自查清单
访谈结束后按以下清单逐项核对，判断本轮访谈是否达到可用标准：
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 目标与假设 | 访谈前已写下决策问题和3–5条待验证假设 | 无任务说明即开始招募 |
| 受访者覆盖 | 符合画像，且覆盖画像中的关键类型 | 全部受访者来自同一类型 |
| 提纲质量 | 以行为回溯为主，无明显诱导性提问 | 提纲以假设性、是非题为主 |
| 记录完整性 | 每场有编号、原话摘录和行为记录 | 记录无法回溯到受访者 |
| 洞察证据 | 每条洞察标注证据出处和覆盖数量 | 洞察无出处或仅凭印象 |
| 下一步动作 | 已形成可验证的需求候选或假设 | 结论停留在描述层面 |
出现以下情况时安排回访或补充访谈：关键画像类型缺失、某条重要洞察只有单一受访者支撑、记录中待跟进问题影响结论方向、或访谈后发现决策问题本身需要调整。补充访谈优先针对缺口类型招募，不必重复已完成的部分。
常见问题
访谈提纲已经定稿，执行中遇到受访者跑题或提前讲完，怎么处理？
提纲是覆盖关键话题的保障，现场节奏可以调整。受访者跑题时，先用一句承接把话题拉回具体经历，例如“这个情况我记下了，回到刚才那一步，你当时具体怎么操作的”。如果某个主问题受访者已经在前面的叙述中回答过，直接跳过，把时间留给追问。
受访者提前讲完时，优先补问记录中的待跟进点，其次确认关键行为的时间、工具和结果是否讲清楚。剩余时间不必强行填满，提前结束并当天整理记录，比拖长访谈更有效。
只有产品经理一个人，没有专职记录人，访谈还能做吗？
可以做，但需要调整分工和记录方式。单人访谈时优先保证记录完整：征得同意后录音，现场只记关键词和时间点，访谈结束后当天对照录音补齐原话。追问深度可以适当收敛，把需要展开的问题列入待跟进清单，通过后续回访或补充访谈解决。
如果条件允许，邀请一位设计师或运营同事旁听并承担记录，成本不高，但能明显减少现场遗漏。无论哪种方式，受访者编号、画像信息和原话出处都要保留，否则后续编码无法回溯。
访谈做了五六场，观点分散，怎么判断哪些结论可以进入需求池？
先看证据强度和覆盖范围，而不是看哪条观点听起来最合理。把相同或相近的标签归并后，统计出现的受访者数量和画像类型分布：跨越不同角色或使用阶段反复出现的模式，证据更稳；只出现在个别人身上的观点，标注为个别情况，暂不作为需求依据。
进入需求池的条目要写清要解决的问题、预期改变的行为和来源洞察编号，方案细节留到需求评审讨论。证据不足但方向重要的条目，可以先写成待验证假设，安排回访或数据交叉验证后再决定是否排期。
访谈结论和后台数据不一致时，应该信哪个？
两者回答的问题不同，通常需要放在一起看。访谈适合解释行为背后的原因和决策过程，数据适合反映行为发生的规模和分布。出现不一致时，先核对口径：访谈样本是否覆盖了数据中的主要用户类型，数据统计的时间范围和事件定义是否与访谈中描述的行为一致。
如果口径一致仍然矛盾，把差异本身作为待验证问题：补充访谈特定类型用户，或调整数据口径重新观察。结论中同时保留访谈证据和数据证据，并注明适用范围，避免用单一来源覆盖全部判断。
一轮访谈结束后，什么情况下需要再补一轮？
常见触发条件有四类：画像中的关键类型没有覆盖到；某条重要洞察只有单一受访者支撑；记录中的待跟进问题影响结论方向；访谈后发现最初的决策问题需要调整。出现这些情况时，补充访谈优先针对缺口类型招募，不必重复已经完成的部分。
补充轮次同样需要更新访谈任务说明，写清本轮要补什么、验证哪条假设。如果缺口来自决策问题本身变化，先与需求方确认新的决策问题，再决定是否继续访谈，避免在错误方向上追加样本。
