UX审计怎么做？从数据、流程到界面的产品体验诊断清单

一份审计报告如果有120条问题，却没有告诉团队哪五条最影响结果，通常只会停在会议里。产品团队不是缺少问题，而是缺少证据、优先级和可执行方案。

UX审计应把定量数据、用户声音、业务规则和界面检查放在同一张图里。它不能代替完整用户研究，但能在有限时间内建立问题基线，帮助团队决定下一轮优化投入。

01 先定义审计要支持哪项决策

“全面提升体验”范围过大。更具体的目标可以是降低注册流失、改善客服工单、评估改版范围、发现B端效率问题，或为下一年度路线图排序。

目标决定审计深度和页面范围。一次两周审计不应假装覆盖整个产品，也不必检查与当前决策无关的所有边角。

02 建立证据地图，而不是只看界面

收集分析数据、漏斗、搜索、错误日志、客服记录、销售反馈、用户访谈、满意度和历史需求。每种资料都有偏差：数据告诉你发生了什么，不一定说明为什么；客服问题来自主动求助者，不代表全部用户。

将证据按用户任务排列，观察多个来源是否指向同一阻力。只有一条主观意见的问题，应标记不确定性。

03 用核心任务作为审计主线

不要按菜单顺序从首页看到设置页。选择三到七条最重要的用户任务，例如首次创建项目、提交审批、支付、邀请成员、处理异常。沿任务检查入口、信息、操作、反馈、失败与完成。

任务视角能发现跨页面问题：重复录入、状态断裂、权限提示太晚、错误后无法恢复。这些通常比单页间距更影响结果。

04 界面走查要结合通用原则与业务规则

启发式原则可检查系统状态、术语一致、用户控制、错误预防和识别负担；可访问性检查关注键盘、焦点、对比、标签和动态内容。B端还应检查权限、审计、批量操作和数据密度。

通用原则不是评分游戏。某个复杂确认步骤看起来增加操作，却可能是金融或医疗业务的必要风险控制，应结合场景判断。

05 每个问题都写成“证据—影响—建议”

“按钮不明显”过于主观。更完整的记录应说明：什么用户在什么任务中遇到什么现象，证据是什么，可能造成什么影响，建议采取什么方向，以及仍需验证什么。

建议不必直接给最终UI，可以提出设计原则、流程调整或实验。审计阶段过早画成精美方案，容易让团队围绕样式讨论而忽略问题。

06 严重度必须同时看用户、业务与修复成本

可用四个维度评分：影响多少用户、是否阻断核心任务、发生频率、业务与合规风险。修复成本单独记录，不应因为难改就降低问题严重度。

高严重度高成本问题可以进入路线图；低成本高影响问题优先快速修；低证据问题先研究。这样比“P0到P3”一个标签更透明。

07 交付物应能直接进入产品计划

完整审计通常包含范围与方法、关键任务地图、证据摘要、问题清单、严重度、机会主题、快速修复、长期路线和验证建议。团队需要Excel或项目管理系统中的可筛选清单，而不只是PDF。

将问题聚类为几个根因，例如导航、数据质量、状态反馈、权限与新手引导。逐条修表面问题，可能会在其他页面重复出现。

08 审计结束后必须验证

修复完成不等于问题解决。根据问题选择可用性测试、事件数据、错误率、任务时间或客服变化进行验证。

UX审计最好形成周期：重大版本前、上线后和关键指标异常时进行，而不是几年一次的“体验体检”。

09 审计报告应区分“修复”与“探索”

有些问题方向明确，如缺少错误反馈、键盘无法操作，可直接进入修复；有些问题只显示异常，如用户在某一步流失，却不知道原因，需要进一步研究。

在路线图中分别标记快速修复、结构改造、数据补充和用户验证，避免团队把所有建议都当成UI任务。对探索项写清要收集什么证据，以及什么结果会改变决策。

这样审计不会把不确定性藏在一张严重度表里，也能让产品、研发和业务按不同工作类型排期。

常见问题

UX审计和可用性测试有什么区别？

UX审计综合数据、专家走查和现有反馈；可用性测试观察真实用户完成任务。两者互补，审计不能完全替代用户测试。

没有数据还能做UX审计吗？

可以做初步专家评估和业务访谈，但结论应标记证据限制，并优先补充关键任务测试与基础埋点。

UX审计需要检查全部页面吗？

不一定。应围绕业务目标和核心任务确定范围，抽查重复模式，再决定是否扩大。

报告应该给出设计稿吗？

可对关键问题提供示意或原型，但审计核心是证据、影响和方向，不必把所有建议做成最终视觉。

如何判断问题优先级？

同时看用户影响、任务阻断、频率、业务风险和证据强度，修复成本作为排期因素单独考虑。