Usability Synthesis

---
name: usability-synthesis
description: Turn raw usability test notes into a structured findings report — observations, affinity-mapped issue groups, task completion metrics, severity × frequency prioritization, and concrete iteration recommendations with verifiable acceptance criteria. Use this skill whenever the user shares usability test notes, session transcripts, user testing recordings summaries, think-aloud logs, or interview observations and wants to know what the problems are, how serious they are, or what to fix first — even if they just say "help me analyze my user testing", "整理一下测试记录", "可用性测试结果怎么分析", or "which issues should we fix first". Also use it for comparing a first round of testing with a retest after iteration.
---

# 可用性测试分析（Usability Synthesis）

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

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

## 工作流程

### 第 1 步：确认输入

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

| 输入 | 是否必需 | 缺失时怎么办 |
|---|---|---|
| 测试记录（笔记、逐字稿、表格均可） | 必需 | 无法进行，请用户提供 |
| 测试任务列表 | 建议 | 从记录中推断，并在报告开头注明"任务为推断" |
| 参与者信息（人数、用户群体） | 建议 | 按记录中出现的参与者编号统计 |
| 测试轮次（首轮 / 复测） | 可选 | 默认按首轮处理；如有两轮数据，执行第 7 步 |

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

### 第 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 步：复测对比（仅当有两轮数据时）

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

## 报告结构

按以下结构输出：

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

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

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

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

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

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

## 后续迭代（P2）

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

## 复测对比（如适用）
```

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

## 示例

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