亲和图做完了，桌上有十几个问题群组，每个群组都有名字——"用户无法识别收藏入口""验证步骤容易被跳过""提交后缺少明确的成功反馈"。卡片里有来自不同用户的观察记录，哪些地方出了问题已经看得很清楚了。

但接下来的问题比较棘手：这十几个问题该先改哪个？收藏入口的问题和提交反馈的问题，哪个对用户的影响更大？"用户无法识别收藏入口"到底是因为图标太小、位置不对、还是图标本身看起来不像一个可点击的按钮？知道了"哪里有问题"，距离知道"该怎么改"还有一段距离。

整理阶段把观察归了类，找出了问题在哪里。分析阶段要做的是下一步——判断每个问题的严重程度，挖出问题背后的原因，把"用户在这里卡住了"变成"这里需要改动什么"。

一. 观察和洞察的区别

分析阶段的核心工作是把观察转化成洞察。这两者的区别贯穿整个分析过程，需要先说清楚。

观察是测试中发生的事实。比如：三个用户在收藏这一步都花了超过三十秒，最终都没有找到收藏入口。观察回答的是"出了什么问题"。

洞察是从观察中提炼出来的、能指导设计改动的判断。比如：收藏图标没有文字标签，图标的颜色和周围的装饰性元素一致，用户无法从图标本身判断这是一个可点击的功能入口。洞察回答的是"为什么出了这个问题"，并且指向"应该改什么"。

两者的区别决定了报告的实用性。如果报告里只写观察——"三个用户找不到收藏入口"——产品团队知道了有问题，但不知道该怎么改。如果报告里写到了洞察——"收藏图标缺少文字标签，视觉权重不足，用户把它当成了装饰"，那么设计师可以直接把这条结论转化成一个设计任务：给图标加文字标签，调整图标的颜色对比度。

二. 问题严重程度分级

拿到亲和图之后，第一步不是挖根因，而是判断每个问题的严重程度。不可能所有问题都在下一个版本里改完，产品团队需要知道应该先改哪些。

评估严重程度看两个维度：发生频率（几个用户遇到了这个问题）和影响程度（这个问题对用户完成任务的阻碍有多大）。两个维度综合判断，分成三个级别：

用户无法独立完成任务，最终需要主持人介入或者放弃任务。判断的依据是行为结果——任务是否完成——而不是主持人的主观感觉。如果两个以上的用户在同一个任务上失败，这个问题通常属于严重级别。有些问题即使只出现在一个用户身上，但性质是任务完全失败，在真实使用场景中意味着用户直接流失，也应该列为严重。

用户最终完成了任务，但过程中遇到了明显的困难——停顿超过三十秒、走了错误路径又折返、误操作之后才纠正过来、口头表达了明确的困惑。任务完成了，但完成得不顺畅。