第 3 章：访谈信息整理 — 从原始记录到结构洞见
仅仅完成用户访谈并收集到大量录音或潦草笔记，并不等于需求的诞生。原始访谈数据是“定性金矿”，但若缺乏系统化的整理方法，这些信息只是一堆杂乱的对话碎片。本章将讲解如何通过编码、提炼与归类，将模糊的用户声音转化为可被后续看板设计直接引用的结构洞见。
3.1 定性数据编码方法
编码是将文本片段附着意义标签的过程。在看板需求分析场景中，编码能帮助我们将用户的口语化表达抽象为具体、可衡量的需求陈述。
| 编码类型 | 核心操作 | 在看板需求中的示例 |
|---|---|---|
| 开放式编码 | 逐句或逐段阅读，发现初始概念 | 用户说：“我每天要花半小时检查项目进度。” → 编码为“高频进度核对” |
| 轴心编码 | 建立概念间的因果、时间或功能关联 | “高频进度核对” → “缺乏自动化预警” → “容易因信息滞后造成风险” |
| 选择性编码 | 提炼核心类别，围绕核心展开叙事 | 核心类别：“低效的进度同步机制” |
实操建议： 初期编码时，建议先用便签纸或在线白板进行开放式编码。每张便签只写一个核心概念，便于后续进行物理或虚拟的拖拽归组。
3.2 关键发现提炼与亲和图法
编码结束后，我们往往面临几十甚至上百个零散概念。此时，亲和图法（Affinity Diagramming）是产品经理必须具备的结构化技能。
执行步骤：
- 步骤 1： 将编码后的便签打乱，随机张贴在墙面上。
- 步骤 2： 团队成员静默移动便签，将感觉有内在联系的便签放在一起。禁止讨论，避免强人主导。
- 步骤 3： 为每组便签创建一个标题卡片（关键发现）。例如：“用户期望全局搜索功能”或“WMS 系统的库存同步有严重延时”。
- 步骤 4： 将各组标题卡片进一步归并为更高维度的“主发现”，通常 3-5 个主发现即可覆盖 80% 的核心需求。
关键发现示例对照表：
| 原始用户语录 | 开放式编码 | 亲和分组（关键发现） |
|---|---|---|
| “我不知道这批货到底卡在哪个环节了。” | 物流节点不透明 | 用户缺乏端到端的可视化追踪能力 |
| “客户打电话来的时候，我都是凭经验猜时间。” | 预估依赖经验而非数据 |
3.3 用户痛点归类框架
并不是所有痛点都会影响后续看板指标的设计。我们需要将关键发现归类，以确定其在需求文档中的优先级。
| 痛点类型 | 描述 | 对看板设计的启示 |
|---|---|---|
| 功能性痛点 | 系统缺少核心功能，或功能无法满足业务场景 | 必须作为新模块或接口纳入看板规划 |
| 可用性痛点 | 功能存在，但交互路径过长、视觉混乱或响应迟钝 | 应优化看板布局、缩短操作路径或增加过滤器 |
| 情感性痛点 | 用户在使用过程中感到焦虑、不信任或挫败 | 需增加确认提示、数据时效性标识或异常申诉入口 |
避坑提示： 产品经理容易陷入“确认偏误”，即只关注支持自己预设观点的访谈信息，而忽略相互矛盾的数据。务必确保编码和归类过程保留原始语境，若发现负向案例，应该作为异常需求记录在案。
3.4 流程整合：用户声音 → 可落地的指标
下图展示了从原始访谈录音到最终看板指标定义之间的完整转化路径。建议在每个新项目中将此流程可视化，帮助团队建立统一的需求析出框架。
通过以上流程，我们能够将录音中杂乱的信息，逐步转化为可读、可验、可追踪的需求项。下一阶段，我们将基于这些结构化的痛点与发现，进入指标定义和看板原型设计环节。