把访谈笔记整理成产品发现，同时保留分歧

把一句陈述整理成产品发现之前，先将问题、说话者和所处情境保留在它旁边。再比较每个人描述自己做了什么、遇到什么困扰，以及怎样应对。重复出现的词可以帮助定位材料，却不能证明每个人都有相同需要。

一位公开发帖者描述过，在 AI 辅助综合访谈材料时，采访者说的话被归到了参与者名下。另一位则询问如何从大量访谈材料中找出共同主题。这些都是个人自述，精确发帖日期尚未核实。它们不能说明某个工具当前的可靠性，也不能验证下述做法。

下面的完整示例全部是虚构的。访谈片段、人物、项目、提取结果和摘要都为教学而编写；没有开展访谈，也没有测试综合分析工具。这是一项实际可练习的整理示范，不是经过认证的研究程序。

从三段完整访谈片段开始

虚构的 Juniper 团队通过共享排班表和消息安排班次。这三段片段来自彼此独立的对话。I 是采访者。P1 和 P2 是团队成员；P3 负责协调变更。话轮编号保留各片段内部的发言顺序。它们不代表真实客户样本。

E1：成员核对变更后的安排

E1-T01 · I:
自动提醒能帮你避免错过班次吗？

E1-T02 · P1:
周日的提醒本来就会送到。上次换班时，我和对方
在那条提醒之后通过聊天达成了安排，但排班表上
仍然是我们原来的班次。

E1-T03 · I:
看到这个情况后，你做了什么？

E1-T04 · P1:
我重新打开聊天和排班表，出发前又给协调人打了电话。
对方说换班已经确认，并告诉我应按哪个开始时间来。
我就照那个答复做了。我不知道原本应该由谁
更新排班表。

E1-T05 · I:
再来一条提醒能解决当时的问题吗？

E1-T06 · P1:
如果只是重复旧排班表，就不能。我想知道
究竟可以按哪一份安排去行动。

E1-T07 · I:
没有换班的那一周，你怎么做？

E1-T08 · P1:
看一遍排班表就去了。这样的周里，
我不想再收到额外通知。

采访者先提到了自动提醒，P1 才开始描述那次事件。P1 讲的是聊天与排班表给出不同信息，随后打电话向协调人核对。P1 没有说自己错过了班次。这段片段也无法告诉我们：如果采访者没有先建议提醒，P1 是否会主动提起它。

E2：成员描述平常的一周

E2-T01 · I:
说说最近一个平常的工作周里，你是怎么使用排班表的。

E2-T02 · P2:
周一我打开已发布的排班表，核对自己的班次，
再记到日程本里。我的工时通常都一样。

E2-T03 · I:
如果每次上班前都有一条提醒，会增加什么帮助？

E2-T04 · P2:
我把常规通知都静音了。一周的安排记下来之后，
对于这套日常流程，我就不需要再来一条提醒。

E2-T05 · I:
上次记到日程本之后又发生换班时，是什么情况？

E2-T06 · P2:
最近没有碰到这种情况，
所以我没有例子可以讲。

P2 提供了平常一周的做法，以及在这种日常流程中不想增加提醒的理由。这里没有近期处理变更的故事。不要把这种材料缺失，变成“P2 从不遇到变更”或“总能轻松处理变更”的结论。

E3：协调人区分确认与给自己的提醒

E3-T01 · I:
按顺序讲讲你最近协调的一次换班。

E3-T02 · P3:
我先把请求标为待定，请双方确认，然后更新
共享排班表，再发一条附有排班表链接的已确认消息。
之后没有人再回来问那次换班的事。

E3-T03 · I:
在你的工作里，提醒用在哪些地方？

E3-T04 · P3:
如果我说需要提醒，指的是双方确认之后，提醒我自己
把更新做完，不是再给排班表上的每个人发一条通知。

E3-T05 · I:
如果有人在你不在的时候开始商量换班，会怎样？

E3-T06 · P3:
有时大家在聊天里说好了，却没告诉我双方是否
都已经确认。改排班表前，我会再问两个人。
只有一个人的消息，还不足以让我把它当成已确认。

E3-T07 · I:
把消息自动化，能消除这种不确定吗？

E3-T08 · P3:
我说不准。一条消息可能仍然只是在说一个请求，而不是已经
达成的变更。我刚才讲的那次，是按确认步骤做的，
过程很顺利。

P3 用“提醒”指自己在确认后的收尾工作。这与提醒成员何时上班不同。那次据称顺利的例子也很重要。P3 说没有人回来提问，并不等于直接观察到每位成员都理解了安排，但摘要也不能抹掉这个案例。

写主题之前，先逐轮提取

下表对完整访谈片段做了人工提取。简短描述可以回溯到上方的完整措辞。采访者的问题也保留在表中，因为它们能解释功能建议从哪里来；这些问题不是参与者提出的需求。

有些话轮包含不止一种陈述。P1 在 T04 中的行动是报告的行为；不知道应由谁更新排班表，则是报告的信息缺口。两者都不能确立应用的实际实现行为。保留这些边界，后面才更容易说明一份简短发现的依据。

比较情境、行为、困难与现有应对

现在把每段对话内部的话轮结合起来，但不要将不同的人混成一个人：

这张表保留了角色差异。P1 要决定按什么安排行动。P3 需要取得足够确认，才能更新共享安排。他们的故事可以共同帮助形成一个产品问题，同时仍涉及不同的行动与责任。

尝试两种相互竞争的归类

按功能话题归类，可以作为索引：

这些标题容易阅读，但“提醒”里面包含一项建议的功能、一项已有输入、一次拒绝，以及协调人自己的请求。同一句陈述可能落入多个标题下。因此，这种归类是索引，不是一组独立投票，也不是共同需求。

按情境归类，会显露另一种模式：

对于“安排变化时，什么变得困难？”这个问题，选择 B 作为主要讨论方式，将 A 保留为功能话题索引。B 让行动与情境更贴近，但仍可能过度强调确认，隐藏 P3 给自己的提醒需求。应保留最后一行，而不是为了让故事整齐就删掉它。

这是对同一组少量虚构材料的两种编辑整理。换一个问题，可能就适合另一种整理方式。两种归类都不是经过认证的方法，也不是自动发现的结果。

修正一份编造共识的摘要

下面是一份故意写错的摘要，同样是为练习编写的，不是从模型捕获的输出：

三位参与者都要求自动提醒，因为迟到的通知让他们错过了班次。他们都使用同一个手机应用，所以产品应该把每次变更发给所有人。

它听起来像明确的产品方向，但访谈片段并不支持它：

一份更有用的暂定发现是：

F1 — 识别变更后的安排。 在这些虚构片段中，P1 已收到常规提醒，但换班讨论与排班表给出不同信息时，仍会向协调人核对。P3 既描述了确认信息缺口，也报告了一段区分待定请求与已确认变更的顺利流程。P2 报告自己的日常安排稳定，不想为此增加提醒，而且没有近期换班例子。这些材料指向的是关于确认和更新交接的问题，而非大家共同要求更多提醒。P3 给自己的收尾提醒，仍是一项单独的想法。

P2 对普遍化的“所有人”结论构成挑战。但 P2 没有近期换班例子，因此不能反驳一个专门针对变更的问题。P3 的顺利案例则是一个与困难案例形成对比的变更案例，不过我们只有协调人的报告。它提示我们可以追问那次为什么清楚，却不能证明某套具体流程造成了该结果。

修订后的段落更长，是因为它保留了会影响下一步决定的区别。用于幻灯片时可以缩短，同时保留能回溯来源的表格。不要只为了让标题更有力，就删掉反例。

把发现转成一个产品问题

一个可以继续调查的候选问题是：

换班讨论之后，如果讨论内容与共享安排不同，成员可能不确定该按哪份安排行动。

这是练习中提出的问题框定，不是对真实人群出现频率的陈述。产品问题是：

成员与协调人怎样判断，一项提议的变更已经确认，并且已经反映在应当遵循的安排中？

同时保留一个替代解释：即使现有界面足够好，责任不清或交接不完整，也可能造成相互冲突的信息。P1 不知道该由谁更新排班表；P3 说需要取得双方确认。这些片段不能确立主要应该改变的是工具、工作约定，还是别的东西。

下一次对话中，一个具体问题可以是：

想一想你最近处理的一次换班。从最初提出请求，
到有人按安排采取行动，你用了哪些消息或排班表记录，
是谁修改它们，又是怎样判断变更已经确认的？

既允许对方讲困难例子，也允许顺利例子。如果没有近期相关事件，就保留这个回答，不替对方补一段想象的故事。本例没有开展下一次访谈或产品实验。

复用一份范围明确的综合请求

使用助手整理已有材料时，可以在请求中明确你希望保留的区别：

使用给定的完整访谈片段，保留话轮顺序
与说话者标签。产出一份产品发现讨论，不是编程
任务说明，也不声称研究已经验证了某项功能。

先逐轮提取。将采访者的问题和建议，
与参与者报告的行动、偏好和不确定性分开。
不要把采访者的自动提醒问题，改写成
参与者的需求。不添加事件、应用名或缺失回答。

比较每位参与者的情境、行为、困难和现有
应对。对同一材料展示两种合理归类，解释
各自揭示或隐藏了什么，并说明哪种适合当前问题。
让“提醒”一词的不同含义仍可区分。

写一份带有精确来源话轮引用的暂定发现。包含
P2 的稳定日常与缺少近期换班例子，以及 P3 报告的
顺利换班。把协调人给自己的提醒保留为单独想法。
不要将重复提及或多个话轮，当作独立投票。

返回一个候选产品问题、一个替代解释，以及
一个供未来对话使用的具体问题。说明材料
无法确立什么。让解释与原始片段的措辞
可以区分；保留原件不变。

一张简短发现卡，随后可以容纳拟议解释、支持话轮、相反或限制性话轮、替代解释和下一问题。最终产物是一份可以通过回到片段原文来质疑的讨论，不必以功能决定收尾。