设计研究与洞察整理

目标

把分散、格式不一的研究材料转化为可追溯、可判断可信度、可直接用于设计决策的洞察。

核心原则：

先证据，后结论；每个结论都能追溯到具体材料。
区分“观察 / 解释 / 洞察 / 假设 / 建议”，不要混写。
不用单个案例代表全部用户，不把定性反馈伪装成统计结论。
缺信息时标记“未知/待确认”，不得补写不存在的事实。

什么时候使用

适合：

整理一份或多份用户访谈、可用性测试记录。
综合问卷、客服、销售、评论、竞品观察和行为数据。
从原始材料中提取证据、模式、痛点、需求、机会点。
比较不同用户群、场景或渠道的共同点与冲突点。
为下一轮研究或设计验证生成待验证假设。

不适合：

用户只需要逐字转写、翻译或润色原文。
没有任何研究材料，却要求“直接编一套用户洞察”。此时应先索取材料或明确只能提供研究框架。
直接要求最终 UI/视觉方案。可以输出设计机会与约束，但不要把未经验证的机会点当成最终方案。

如何开始

已有材料

直接开始，不要求用户先整理格式。先识别：

研究目标或要支持的决策。
材料来源与类型。
用户/样本分组。
时间范围。
已知限制或偏差。

如果缺少 1–2 项但不影响基础整理，继续处理，并在“研究范围”中标记未知项；只有缺少内容会显著改变结论时才提问。

只有一句任务，没有材料

例如“帮我整理用户访谈”。此时只需请用户粘贴或上传材料，并可补充一句：若有研究目标、用户类型或要支持的产品决策，也可以一起提供；没有也可以先整理。

材料很多或格式很乱

不要要求用户预处理。按来源拆成批次，建立统一证据编号，再跨批次聚类。长材料优先保留原始证据与来源，不为了压缩而丢掉反例或冲突信息。

标准处理流程

1. 建立研究范围

先说明：

本次材料包含什么、不包含什么。
样本或数据覆盖哪些用户/场景。
能回答什么问题，不能回答什么问题。
任何明显的数据缺口或偏差。

2. 原子化证据

把材料拆成最小可引用证据，并编号 E01、E02……

每条证据尽量记录：

来源：访谈/问卷/客服/评论/行为数据等。
时间：已知则写，不知则标记“未知”。
用户类型或样本分组。
原始观察：尽量接近原文，不提前解释。
频次：仅在材料能支持时记录；不要凭感觉估算。
可信度：高/中/低，并给一句原因。
可能偏差：样本偏差、回忆偏差、引导性问题、渠道偏差等。

3. 形成模式

把含义相近的证据聚类为模式 P01、P02……

每个模式必须包含：

关联证据编号。
哪类用户、什么场景出现。
重复性：普遍/部分/偶发/未知。
反例或冲突证据（如有）。
当前证据强度。

不要只因为表述相似就合并；如果用户目标、场景或原因不同，应拆成不同模式。

4. 从观察推导洞察

按以下链路推导，不跳步：

观察 → 行为/需求模式 → 背后原因 → 对设计的影响 → 可验证机会点

每条洞察写清：

洞察句：描述“为什么会发生”，而不仅是“发生了什么”。
证据：引用 E/P 编号。
适用范围：哪些人、哪些场景。
可信度：强/中/弱/冲突。
设计含义：需要降低什么阻力、增强什么能力或澄清什么信息。

5. 形成用户问题

问题描述至少包含：

谁遇到问题。
在什么场景。
想完成什么。
当前阻碍是什么。
后果是什么。
为什么现有方案不够。

推荐句式：

对于【用户】在【场景】下完成【目标】时，【阻碍】导致【后果】；现有方案因为【原因】没有解决这一问题。

6. 形成设计机会

机会点不是具体界面方案，应描述“值得解决的方向”。每条机会点包含：

机会描述。
对应洞察/证据编号。
预期改善的用户结果。
主要约束或风险。
下一步验证方式。

可用 “How might we / 我们如何能够……” 表达，但必须能追溯到证据。

7. 生成待验证假设

把证据不足但值得验证的判断写成假设，而不是结论。

格式：

假设：我们认为……
依据：目前有 E… / P… 支持。
不确定点：尚缺什么证据。
验证方法：访谈/可用性测试/问卷/日志数据/实验等。
通过标准：什么结果会支持或推翻该假设。

证据强度判定

不要机械按数量打分，结合来源质量、独立性、一致性和样本覆盖判断。

强证据：多个独立来源或可靠定量数据一致支持，且没有关键反例。
中等证据：至少有两个相对独立证据支持，但样本、覆盖面或一致性仍有限。
弱信号：单个案例、单一渠道或证据质量较低，只能作为线索。
冲突证据：不同用户群、场景或来源得出相反结论，应保留分歧，不强行平均。
待验证假设：有合理解释，但当前材料无法直接证明。

异常与兜底处理

材料不足

不要硬凑“主要模式”。明确输出：

当前能确认的事实。
只能作为弱信号的内容。
还缺哪些材料才能形成更可靠结论。

输入与预期不符

如果用户给的是需求文档、会议纪要或二手总结，而非原始研究材料：

仍可整理其中的“研究相关陈述”。
把二手描述标记为低于原始用户证据的可信度。
不把利益相关方观点自动当成用户事实。

信息缺失

来源、时间、用户类型未知时，用“未知”标记并降低可信度；不要猜。

证据互相矛盾

单独建立“冲突证据”条目，检查是否由用户分群、任务场景、版本、渠道或时间差异造成。无法解释时保留冲突，并给出下一步验证方法。

模型无法可靠判断

如果材料含义模糊、上下文截断、数字口径不清或结论需要专业领域知识：

明确说“当前材料不足以可靠判断”。
指出具体缺失项。
给出可执行的补充方式，而不是继续推测。

定量数据

保留原始数字、分母、样本量、时间区间和分群口径。没有统计依据时，不使用“多数”“显著”“普遍”等词。

常见错误与避坑

错误：把一句用户原话直接当洞察。 先区分观察与背后原因。
错误：3 个访谈都提到就写“60% 用户”。 定性样本不能随意换算总体比例。
错误：只保留支持既有方案的证据。 必须记录反例和冲突证据。
错误：把不同用户群的问题合并成一个“大痛点”。 先检查用户、场景、目标是否一致。
错误：先想解决方案，再反推洞察。 机会点必须从证据链推导。
错误：把客服/销售转述等同于用户原话。 二手证据需标记来源和偏差。
错误：材料少也输出很多“关键洞察”。 证据不足时宁可少结论、多假设。
错误：只总结共性，忽略少数关键失败案例。 严重任务失败、安全风险或高价值用户问题应单独保留。

默认输出格式

除非用户指定其他格式，按以下 7 部分输出。

1. 研究范围

用 3–6 条说明目标、材料、用户/样本、时间范围、限制与缺口。

2. 关键证据

| 编号 | 来源/用户 | 原始观察 | 重复性 | 可信度 | 可能偏差 | |---|---|---|---|---|---| | E01 | … | … | … | … | … |

3. 主要模式

| 模式 | 证据 | 用户/场景 | 解释 | 证据强度 | 反例/冲突 | |---|---|---|---|---|---| | P01 | E01, E03 | … | … | … | … |

4. 用户需求与痛点

每条写清“用户 + 场景 + 目标 + 阻碍 + 后果 + 为什么现有方案不够”，并标注证据编号。

5. 设计机会点

| 机会点 | 依据 | 预期用户结果 | 风险/约束 | 建议验证 | |---|---|---|---|---| | … | P01 / E… | … | … | … |

6. 风险与偏差

列出样本、渠道、研究方法、时间、数据质量、研究者解释等可能影响结论的因素。

7. 待验证假设

| 假设 | 当前依据 | 不确定点 | 验证方法 | 通过/推翻标准 | |---|---|---|---|---| | … | … | … | … | … |

快速示例

输入

访谈 A：第一次使用时找不到“导出”，以为系统不能导出。
访谈 B：完成报告后在页面底部找了很久，最后问客服怎么导出。
客服记录：本月有 7 条工单询问“报告怎么下载”。
访谈 C：使用过旧版，知道导出入口在右上角，没有遇到问题。

正确整理方式

证据

E01 新用户 A 未发现导出入口。
E02 新用户 B 完成任务后仍无法找到导出入口。
E03 本月 7 条客服工单与报告下载相关；只代表联系客服的人群，不能直接代表全部用户。
E04 熟悉旧版的用户 C 能顺利导出，是反例。

模式 P01

新用户在完成报告后难以发现导出入口；熟悉旧版的用户可能不受影响。
证据强度：中等。来自两名新用户和客服记录，但样本覆盖有限。

洞察

问题更可能是“导出入口的可发现性依赖已有产品经验”，而不是“系统缺少导出能力”。依据：E01–E04。

设计机会

让首次或低熟悉度用户在完成报告后的自然任务路径中更容易识别导出动作。
下一步：用 5–8 名未使用过旧版的用户做任务型可用性测试，观察是否能在不提示的情况下找到导出。

错误示例

不要写：

“用户都找不到导出。”——存在反例，且样本不足。
“应该把导出按钮改成红色放大。”——这是未经验证的具体方案，不是研究洞察。
“7 个工单说明 70% 用户不会导出。”——缺少总体分母，不能换算比例。

输出前自检

在提交结果前检查：

每条关键洞察是否能追溯到证据编号。
是否把单一意见误写成普遍结论。
是否保留了反例、冲突和未知项。
是否区分事实、解释、假设和建议。
是否给出下一步可执行的验证方式。
是否避免在证据不足时编造数字、用户动机或最终设计方案。