从访谈、观察和使用场景材料中提炼用户痛点，关键是把零散素材转成可追溯、可排序、可验证的痛点清单。做法是先把三类材料统一编号并保留出处，再按“情境—行为—障碍—后果”拆成结构化片段，归并为痛点陈述，用频次、影响面和可改变性筛选优先级，最后回到用户处做小样本验证。整个过程需要研究、产品、设计等角色按节点交接，避免痛点停留在个人印象层面。
要点总览（TL;DR）
- 先把访谈、观察和使用场景材料统一编号并标注出处，区分原话、观察事实与研究者推断，保证每条痛点都能回溯到具体片段。
- 按“情境—行为—障碍—后果”拆解单条材料，再以同一角色、同一场景、同一障碍类型为判据归并为痛点陈述，陈述中只写问题不写方案。
- 用频次、影响面和可改变性三项标准筛选优先级，证据不足的条目标注为待验证，不强行打分也不直接删除。
- 内部筛选后回到目标用户处做小样本、多轮回访，按确认、修正、否定三类结果修订清单，并保留修改痕迹。
- 交付前核对可追溯性、陈述质量、优先级依据、验证状态和交接完整性，任一阻断项未通过则不进入正式交付。
提炼前先把材料整理成可追溯的原始记录
三类材料进入分析前，先统一编号和出处标注。这样做的目的很直接：后续每条痛点都能回溯到具体片段，评审时能判断结论是否有依据，而不是凭印象争论。
访谈、观察和使用场景材料的记录字段可以按下面的口径整理：
| 材料类型 | 必填字段 | 出处标注方式 |
|---|---|---|
| 访谈记录 | 受访者编号与角色、访谈时间、问题编号、原话摘录、访谈者备注 | 受访者编号＋问题编号，例如“U03-Q5” |
| 观察记录 | 观察场景、时间、被观察对象角色、记录方式（现场笔记/录屏/照片说明）、观察事实 | 场景编号＋时间点，例如“O02-14:20” |
| 使用场景材料 | 场景名称、任务目标、材料来源（用户提交/后台记录/演示复现）、操作步骤描述 | 场景编号＋材料来源，例如“S01-用户提交” |
整理时要把三类内容分开标注：原话是用户自己说的，保留原始措辞；观察事实是研究者看到的行为和界面状态，只写发生了什么；研究者推断是对原因或动机的解释，单独标记为“推断，待验证”。三者混在一起，后续归并时容易把假设当成证据。
完成标志是一份带编号和出处的原始记录表，每条记录都能被独立引用，且推断内容有明确标记。
按情境—行为—障碍—后果拆解单条材料
原始记录整理好后，逐条拆成四要素片段。四要素的判定方法是：情境指用户所处的任务背景和触发条件，例如“月底对账时收到多笔异常订单”；行为指用户实际做了什么，例如“逐条打开订单核对金额”；障碍指过程中卡住或绕行的地方，例如“异常原因分散在三个页面，需要反复切换”；后果指障碍带来的时间、成本、错误或情绪影响，例如“单笔核对耗时增加，容易漏看”。
操作步骤可以按以下顺序执行：
- 输入一条原始记录，先定位情境，写清任务目标和触发条件。
- 按时间顺序记录行为，只写可观察的动作，不写“用户觉得麻烦”这类判断。
- 标出行为中断、绕行或反复的位置，作为障碍。
- 记录障碍之后发生的结果，区分时间成本、操作错误和情绪反应。
- 输出一条结构化片段，附原始记录编号。
常见拆解错误有三类：把推断写进行为，例如“用户因为不信任系统所以手动复核”，需要拆成“手动复核”这个行为和“不信任”这个待验证推断；把多个障碍塞进一条片段，导致后续无法归并；后果写得过于笼统，例如“体验不好”，应改为可观察的影响，如“每次核对多花几分钟”或“出现重复提交”。
完成标志是结构化片段清单，每条片段包含四要素、原始出处和推断标记。
把片段归并为可验证的痛点陈述
归并同类片段的判据是“同一角色、同一场景、同一障碍类型”。三个条件同时满足才合并，避免把不同场景下的相似表述强行并成一条。例如两位用户都提到“找不到入口”，但一位在首次使用时、另一位在权限变更后，场景不同，应保留为两条或标注为同一障碍的不同情境变体。
痛点陈述建议用固定模板：在【场景】下，【角色】想完成【任务】，因为【障碍】导致【后果】。 这个模板强制写清角色、场景、障碍和后果，评审时可以直接判断是否成立。
写法上要注意两点：一是痛点陈述只描述问题，不写解决方案。“希望增加一键导出”是方案，对应的痛点可能是“在汇总多个来源数据时，需要逐条复制，导致整理时间过长”。二是后果要尽量具体，能对应到时间、错误率、返工次数或情绪反应，避免“效率低”“体验差”这类无法验证的表述。
完成标志是痛点陈述初稿，每条陈述都能指向一条或多条结构化片段，并标明合并了哪些片段。
用频次、影响面和可改变性筛选优先级
痛点陈述成立之后，需要判断哪些更值得优先处理。三项标准的定义和取数方式如下：
| 标准 | 定义 | 取数方式 |
|---|---|---|
| 频次 | 同一痛点在不同受访者或场景中出现的次数 | 统计指向该痛点的片段数和独立来源数 |
| 影响面 | 涉及的角色数量与任务关键程度 | 标注受影响角色，判断任务是否属于核心流程 |
| 可改变性 | 团队是否有条件通过产品、流程或信息设计干预 | 由产品、设计、研发评审确认干预空间 |
打分可以采用高、中、低三档，先按频次和影响面排序，再用可改变性做修正。权重取决于当前业务目标和团队资源，没有统一口径，建议在评审时明确本轮的取舍规则并记录。证据不足的条目，例如只有一位用户提及、且未在观察中复现，标注为“待验证”，不强行打分，也不直接删除。
完成标志是带优先级的痛点清单，每条包含三项标准的取数依据和证据出处。
角色分工与各环节交付物
提炼流程涉及多个角色，职责和交接物需要提前明确，否则容易出现材料整理完无人归并、清单写完无人验证的情况。
| 环节 | 主要负责角色 | 参与角色 | 交付物 |
|---|---|---|---|
| 材料整理 | 用户研究员 | 访谈执行人 | 带编号和出处的原始记录表 |
| 片段拆解 | 用户研究员 | 产品经理 | 结构化片段清单 |
| 痛点归并 | 产品经理 | 用户研究员、设计师 | 痛点陈述初稿 |
| 优先级初判 | 产品经理 | 设计、研发 | 带优先级的痛点清单 |
| 回访验证 | 用户研究员 | 产品经理 | 验证记录与修订后的清单 |
交接节点设在片段清单完成、痛点初稿完成和验证完成三个位置。每次交接需要验收：片段是否都有出处，痛点陈述是否包含四要素，优先级是否有取数依据。评审采用短会形式，由归并负责人逐条说明证据来源，设计和研发重点确认可改变性，避免评审变成方案讨论。
当痛点清单需要在多人之间流转、评审和持续修订时，可以把清单条目作为工作项管理，把原始记录和验证记录放在关联文档中，让每条痛点的状态、负责人和证据出处保持同步。ONES 的文档与工作项管理可以承载这类流转：研究材料沉淀为文档，痛点条目对应工作项，评审意见和验证结论回写到条目上，便于后续需求讨论时直接引用。
一个完整示例：从三段材料到一条痛点
以下为演示情景，用于说明流程，不代表真实研究结论。
原始片段示例：访谈记录 U05-Q3 中，受访者（运营专员）说：“每次活动结束对账，我要把后台订单和财务表来回对，遇到退款单还得翻聊天记录确认。”观察记录 O03 显示，该角色在对账时打开三个页面，其中两次切换到聊天工具，单笔退款核对用时较长。使用场景材料 S02 记录了一次活动结算任务，材料来源为用户提交的操作录屏，任务目标是在结算日前完成订单与退款核对。
拆解过程：情境是活动结束后的结算对账；行为是打开后台订单、财务表和聊天记录逐笔核对；障碍是退款原因分散在聊天记录中，需要反复切换；后果是单笔核对耗时增加，且存在漏核对风险。三段材料指向同一角色、同一场景和同一障碍类型，可以归并。
痛点陈述：在活动结算对账场景下，运营专员想完成订单与退款核对，因为退款原因分散在聊天记录和多个后台页面，导致逐笔核对耗时增加并存在漏核对风险。
优先级判断：频次为三位受访者中两人提及、观察中复现一次；影响面涉及运营角色且属于结算核心流程；可改变性经评审确认可以通过信息聚合和核对状态记录来干预。综合判断为高优先级，证据出处标注为 U05-Q3、O03、S02。
回到用户处验证痛点
内部筛选完成之后，需要用回访确认痛点是否真实成立。验证问题先开放后确认：先请用户描述最近一次相关任务的经过，再复述痛点陈述，询问是否符合其经历。避免直接问“你是不是觉得这里很麻烦”，这类引导性问题会把确认变成附和。
样本选择以目标角色为主，覆盖不同使用频率的用户，每轮选取少量用户，分多轮进行。第一轮验证高频痛点，第二轮验证修正后的表述和此前标注为待验证的条目。轮次和样本量按研究目的与资源确定，没有统一下限。
验证结果分三类处理：确认的条目保留并补充验证记录；修正的条目按用户表述调整场景、障碍或后果；否定的条目标注否定原因，移出主清单或降为观察项。修订后的清单需要保留修改痕迹，便于后续追溯。
完成标志是验证记录与修订后的痛点清单，每条痛点标明验证状态和验证来源。
完成检查：痛点清单是否可用
交付前逐项核对以下内容，任一阻断项未通过，清单不进入正式交付。
- 可追溯性：每条痛点能否指向具体的原始记录编号或结构化片段；推断内容是否单独标记。
- 陈述质量：是否包含角色、场景、障碍和后果；是否混入解决方案；后果是否具体可观察。
- 优先级依据：频次、影响面和可改变性是否有取数和出处；待验证条目是否明确标注。
- 验证状态：高优先级痛点是否经过回访确认；否定和修正的条目是否记录处理结果。
- 交接完整：原始记录表、片段清单、痛点初稿、优先级清单和验证记录是否齐全，负责人是否明确。
阻断项包括：痛点无法回溯到材料、陈述中只有方案没有障碍、优先级无取数依据。完成条件是该清单可以被产品和设计直接用于需求讨论，且每条结论都能在评审中说明证据来源。
常见问题
只有一两位用户提到的痛点，是否应该直接删掉？
不建议直接删除。可以先标注为“待验证”，保留在清单的观察项中，并记录提及者的角色、场景和原始出处。后续回访时把这类条目作为验证重点，如果在新一轮访谈或观察中复现，再提升优先级；如果多轮验证都没有得到支持，再移出主清单并写明否定原因。这样处理能保留线索，也避免把个别经历当成普遍结论。
访谈中用户直接提出的功能需求，能不能当作痛点使用？
功能需求是用户给出的解决方案，需要再往前追一步，问清他在什么场景下、想完成什么任务、当前卡在哪里、造成了什么后果。把这段经历整理成“场景—角色—任务—障碍—后果”的陈述，才是可分析的痛点。原始需求可以单独记录在材料中，作为后续方案讨论的输入，但不直接进入痛点清单的主体部分。
观察记录和使用场景材料与访谈原话出现矛盾时怎么处理？
先保留双方记录，不急于判断谁对。矛盾本身是有价值的信息，可能说明用户表述与实际行为存在差异，也可能说明场景条件不同。处理方式是在片段中并列标注两类证据，把差异点写成待验证问题，在回访时请用户回顾具体经过。归并时以可观察的行为和材料记录为主，用户自述作为补充，最终结论以验证结果为准。
痛点清单做完后，怎样衔接到需求讨论和后续迭代？
清单需要带上证据出处、优先级取数依据和验证状态，才能被产品和设计直接引用。进入需求讨论时，每条痛点对应一个可讨论的问题条目，方案设计围绕障碍和后果展开，评审时能回到原始材料核对。若清单条目较多、需要多人持续修订，可以把痛点作为工作项管理，原始记录和验证记录放在关联文档中，让状态、负责人和证据出处保持同步。ONES 的文档与工作项管理可以承载这类流转，便于后续需求讨论时直接引用。
团队人手有限时，哪些环节可以简化？
可以简化的是记录形式和评审频次，不宜省略的是出处标注和回访验证。例如原始记录表可以先用统一模板的简版字段，片段拆解由一人完成、另一人抽查；评审可以合并为一次短会。但每条痛点仍需能指向具体材料，高优先级条目仍需经过用户确认，否则清单容易退回个人印象层面，后续需求讨论缺少共同依据。
