可用性测试分析（Usability Synthesis）

把零散的可用性测试记录，整理成一份能直接指导迭代的分析报告：发现了什么问题、有多严重、先修哪个、修完怎么验证。

这个 skill 的核心立场是：结论必须能追溯到观察。小样本测试（通常 5–8 人）最常见的错误，是把个别用户的偏好写成普遍问题，或者跳过观察直接给设计建议。所以整个流程刻意把"看到了什么"和"这意味着什么"分开。

工作流程

第 1 步：确认输入

先看用户提供了什么，缺什么：

不要因为缺少可选信息就停下来追问，先做，把假设写在报告里。

第 2 步：提取观察

逐个参与者、逐个任务，提取事实性观察。每条观察包含：

• 参与者编号（P1、P2…）
• 任务
• 现象：用户做了什么、在哪里卡住、说了什么
• 任务结果：完成 / 在帮助下完成 / 放弃

这一步只记录事实，不解释原因。比如写"P3 在首页停留 40 秒，没有点击无障碍按钮"，而不是"P3 觉得无障碍按钮不明显"。原因留到第 3 步再归纳。

原话只引用记录中真实存在的内容，不要编造或润色用户的话。

第 3 步：亲和图分组

把观察自下而上聚类成问题组：

• 不预设类别，先看哪些观察描述的是同一个问题，再给组命名
• 组名写成问题陈述，而不是功能名称。例如写"用户看不懂法律术语"，而不是"术语模块"
• 一条观察只归入一个组；如果确实涉及两个问题，拆成两条观察
• 只出现一次、且明显是个人偏好的观察（如"我更喜欢蓝色"），单独放入"个别反馈"，不作为问题

第 4 步：量化

计算以下指标，始终同时给出分子和分母（如 3/6），因为小样本下单独写百分比会夸大确定性：

• 每个任务的完成率
• 每个问题组涉及的参与者人数
• 如果记录中有时间数据：平均完成时间、平均放弃时间

第 5 步：严重度 × 频率分级

对每个问题组评估严重度和频率，再合成优先级。分级标准见 references/severity-scale.md，开始分级前先阅读它。

每个问题都要写一句分级理由，让读者能判断你分得对不对。

第 6 步：迭代建议

为 P0 和 P1 问题写迭代建议，每条建议包含：

• 改什么：具体的设计改动，不要写"优化体验"这类空话
• 验收标准：可验证的标准。能量化的尽量量化，例如"文字对比度 ≥ 4.5:1（WCAG AA）"、"点击区域 ≥ 44×44px"、"复测中 ≥ 5/6 的用户无需提示即可完成任务"
• 对应问题：链接回问题组编号

P2 问题列入"后续迭代"清单即可，不必展开。

如果某个问题的根源不是交互设计，而是需求本身有误（比如用户根本不需要这个功能），单独标出来，建议回到需求层面讨论，而不是在界面上修补。

第 7 步：复测对比（仅当有两轮数据时）

用表格对比两轮的任务完成率和问题状态（已解决 / 部分改善 / 未改善 / 新出现），并说明哪些迭代起了作用。

报告结构

按以下结构输出：

# [产品名] 可用性测试分析

## 概要
- 测试规模：N 名参与者，M 个任务（注明用户群体）
- 核心结论：2–3 句话，最严重的问题是什么
- 假设说明：（如任务列表是推断的，在这里写明）

## 任务完成情况
| 任务 | 完成 | 协助完成 | 放弃 | 完成率 |

## 问题清单
| 编号 | 问题陈述 | 涉及人数 | 严重度 | 频率 | 优先级 | 分级理由 |

## 问题详情
### [编号] 问题陈述
- 观察证据：（列出对应的观察，标明参与者）
- 影响：

## 迭代建议
| 优先级 | 对应问题 | 改动 | 验收标准 |

## 后续迭代（P2）

## 个别反馈（未纳入问题清单）

## 复测对比（如适用）

报告用户使用的语言写作。如果用户要求导出为文档或表格，按其要求的格式输出。

示例

完整的输入和输出示例见 examples/ 目录。