UX 审计是对网站或 App 的结构化检查，找出可用性问题并排好修改顺序。本文把启发式评审和漏斗、热图、回放、错误、客服对话这些行为证据结合起来，附一份带量化标准的检查清单，以及一次让结账完成率从 46% 升到 53% 的审计示例。
读完你会知道
- 审计范围限定在几个关键流程
- 漏斗告诉你看哪里，启发式原则解释为什么
- 每个问题步骤看 15–30 段回放
- 怪设计之前先查速度和错误
- 按严重程度 × 影响面 ÷ 工作量排序
什么是 UX 审计？
UX 审计（UX Audit，也叫用户体验审查）是对网站或 App 的一次结构化检查：找出可用性问题，说明它们为什么妨碍用户，并给出修改的先后顺序。它把对照可用性原则的专家评审，和真实用户的使用证据结合起来：统计数据、漏斗、热图、会话回放、错误和客服对话。交付的是一份排好序的问题和建议清单，不是一次改版。
审计负责发现问题，不负责修。它的价值是把设计和开发团队的注意力引向最要紧的几处改动。
什么时候做 UX 审计
- 转化或留存下降了，没人说得清原因。
- 改版之前，弄清楚哪些该留、哪些该改。
- 重要版本上线后，或者结账、注册、新手引导流程换新以后。
- 客服反复收到同样的「怎么做」问题。
- 关键流程每年一到两次，作为例行维护。
专家评审和数据驱动审查
| 启发式（专家）评审 | 数据驱动审查 | |
|---|---|---|
| 怎么做 | 评审人对照尼尔森十大可用性原则、WCAG 等走一遍流程 | 统计、漏斗、热图、回放、错误、客服记录 |
| 能发现 | 前后不一致、标签不清、缺少反馈、无障碍缺口 | 用户实际卡在哪里、影响多少人 |
| 长处 | 快，能在很多用户遇到之前发现问题 | 能看出影响面和优先级 |
| 短处 | 主观，量不出问题大小 | 说明了在哪、有多少，不一定说明为什么 |
好的审计两者都用：数据告诉你看哪里，专家评审解释那里出了什么问题。
| 严重程度 | 含义 | 例子 |
|---|---|---|
| 高 | 在关键流程上挡住或流失大量用户 | 必填字段校验报错 |
| 中 | 拖慢用户或分散注意力 | 结账页显眼的优惠码输入框 |
| 低 | 外观问题或影响很少用户 | 对比度低的次要链接 |
先拿出前十条；很长又不排序的清单很少被修完。
做 UX 审计的七个步骤
1. 定范围和目标
选定要审的流程（比如落地页到注册、商品页到结账），以及每个流程服务的业务指标。没有范围的全站审计，只会得到一长串没排序的问题。
2. 收集行为数据
每个流程收集四周的数据：页面和步骤转化、退出率、滚动深度、狂点、JavaScript 错误、设备构成。漏斗告诉你哪一步流失最多，审计的大部分时间应该花在那里。
3. 看真实会话
在出问题的每一步挑 15–30 段会话回放，筛选流失或有狂点的会话，记下用户想做什么、在哪犹豫。回放能把一个流失百分比变成具体的行为。
4. 做启发式评审
在电脑和手机上各走一遍同样的流程，逐屏对照可用性原则检查：系统状态是否可见、用词是否贴近用户、用户是否有控制权、是否一致、能否预防错误、是否让人认出而不是硬记、是否灵活高效、设计是否简洁、能否从错误中恢复、有没有帮助。再做一轮无障碍检查（对比度、焦点顺序、标签、点击区域）。
5. 查性能和错误
慢的或坏掉的页面，看起来也像可用性问题。怪设计之前，先看审计页面的 Core Web Vitals 和错误。
6. 读客服记录和反馈
用流程相关的关键词搜在线客服记录和工单。反复出现的问题，是体验让人困惑的清楚证据。
7. 排优先级，写报告
每个问题记下：出现在哪、证据（数据和截图）、影响多少用户、严重程度、建议改法和工作量。按「严重程度 × 影响面 ÷ 工作量」排序，先拿出前十条。
UX 审计检查清单
| 方面 | 检查什么 |
|---|---|
| 导航 | 新访客两次点击内能到达主要任务吗？标签用的是用户的说法吗？ |
| 内容 | 每个页面首屏是否回答了把人带来的那个问题？ |
| 表单 | 字段是否精简、有标签、有即时校验和清楚的错误提示？ |
| 反馈 | 按钮有加载和成功状态吗？错误有说明吗？ |
| 移动端 | 点击区域至少 24×24 CSS 像素吗？有没有横向滚动？ |
| 无障碍 | 文字对比度至少 4.5:1 吗？能只用键盘走完流程吗？ |
| 性能 | 第 75 百分位的 LCP 在 2.5 秒内、INP 在 200 毫秒内吗？ |
| 信任 | 价格、配送、退款、安全信息在做决定的地方看得到吗？ |
计算示例：一次结账审计
某网店的结账流程（示例数据，四周）里，开始结账的人有 46% 完成。审计发现：
| 发现 | 证据 | 严重程度 | 改法 |
|---|---|---|---|
| 运费到最后一步才显示 | 38% 的退出发生在支付步骤；回放里用户来回翻回购物车 | 高 | 在购物车里显示预估运费 |
| 邮编字段不接受空格 | 9% 的结账会话在邮编上出现校验错误，「继续」按钮上有狂点 | 高 | 接受空格，在服务端统一格式 |
| 优惠码输入框太显眼 | 22% 的用户点了「使用优惠码」，很多人离开去找优惠码 | 中 | 收进一个文字链接里 |
| 「返回」链接对比度低 | 对比度 2.9:1 | 低 | 提高对比度 |
修好前两项后，接下来四周结账完成率从 46% 升到 53%。
结账 · 4 周
会话开始结账
8,000
填写地址
6,240
选择配送
5,280
支付
4,640
下单完成
3,680
常见错误
- 只有观点，没有证据。 每条发现背后都要有数据、回放或原则。
- 只在电脑上审。 大部分消费类流量来自手机，很多问题只在手机上出现。
- 80 个问题一样重要。 要排序，团队只会处理前十条。
- 忽略性能和 bug。 坏掉的按钮不是设计问题。
- 不跟进度量。 改完要重新看指标，确认审计的判断是对的。
用 TapCub 做 UX 审计
- 漏斗和退出： 给每个审计流程搭一条漏斗，用 网站统计 › 页面 看退出页和跳出。
- 热图和回放： 点击热图和滚动热图显示用户想点什么、在哪停下；狂点会被标出来。会话回放默认关闭，开启后默认采样 10% 的会话，输入内容默认打码。
- 错误和速度： 按页面看 JavaScript 错误和真实用户 Core Web Vitals，把 bug 和慢跟设计问题分开。
- 客服： 在线客服对话会显示访客求助时所在的页面。
常见问题
UX 审计要多久？ 聚焦两三个关键流程的审计，包括收集数据、看回放、启发式评审和写报告，一般需要一到两周。
UX 审计和可用性测试有什么区别？ 审计用专家评审和现有数据审查现有产品；可用性测试是招募参与者、观察他们完成任务。审计常常会指出哪里需要做可用性测试。
UX 审计报告应该包括什么？ 范围和目标、方法、附证据的排序问题清单、严重程度和建议改法，以及改完后要盯的指标。
没有 UX 设计师能做审计吗？ 做首轮可以：数据、回放加一份启发式清单，能找出最大的问题。设计师能帮你提出改法，发现更细的问题。
参考资料
- Nielsen Norman Group：十大可用性原则
- W3C：网页内容无障碍指南（WCAG）2.2
- Baymard Institute：结账可用性研究
这篇文章对你有帮助吗？
我们会根据反馈修改和补充这篇内容。
提交没有成功，请稍后再试。
谢谢你的反馈，我们会据此改进这篇内容。你已经反馈过这篇了，谢谢。
