产品可用性评审的依据由三类材料构成：用户与任务依据（目标用户、核心任务、使用场景）、设计依据（交互流程、原型、文案与异常态说明）、验证依据（可用性测试记录、走查结果、客服与埋点数据）。本文给出可直接对照的依据清单、评审步骤、角色分工与问题分级标准，并说明如何判断一次评审是否闭环。
要点总览（TL;DR）
- 可用性评审的依据分三类：用户与任务依据、设计依据、验证依据；准备阶段逐项确认来源、责任人与是否齐备。
- 评审按五步推进：确定范围与目标任务、材料预读与问题预判、任务走查与问题记录、问题分级与整改分派、复评与关闭。
- 产品、设计、研发、用研各自带着交付物进入评审，记录人与整改跟踪人分别保证问题不丢、不悬空。
- 问题以任务影响分三档：阻断、明显受阻、体验瑕疵；每条问题记录位置、任务、现象、影响，并指定责任人与期限。
- 评审是否达标看三条线是否闭合：依据齐备并标注来源、核心任务全部走查、需复评的问题有结论并归档可追溯。
可用性评审前要准备哪些依据材料
可用性评审的结论要站得住，前提是评审桌上摆着可被引用的材料。依据材料按来源分为三类：用户与任务依据回答“为谁做、要完成什么”，设计依据回答“方案长什么样、怎么走”，验证依据回答“有没有证据表明用户走得通”。三类材料齐备，评审才能从主观偏好转向任务验证。
准备阶段建议由产品负责人牵头，逐项确认材料是否齐备、来源是否可追溯、责任人是否明确。下表可作为评审前的依据清单直接使用。
| 类别 | 材料名称 | 来源 | 责任人 | 使用方式 |
|---|---|---|---|---|
| 用户与任务 | 目标用户画像 | 用户研究、运营数据、销售反馈 | 产品负责人 | 界定评审时的模拟用户身份 |
| 用户与任务 | 核心任务清单 | 需求文档、业务流程梳理 | 产品负责人 | 确定走查任务与优先级 |
| 用户与任务 | 使用场景与频次说明 | 客服记录、埋点、访谈 | 产品/用研 | 判断问题在真实场景中的影响面 |
| 设计 | 交互流程图 | 设计稿、流程说明 | 交互设计 | 核对路径完整性与分支覆盖 |
| 设计 | 可交互原型或高保真稿 | 设计工具产出 | 交互/视觉设计 | 评审会上按任务逐步走查 |
| 设计 | 界面文案与提示语 | 设计稿、文案表 | 交互设计/内容 | 检查表述是否可理解、是否指向下一步 |
| 设计 | 空态、加载态、异常态说明 | 设计规范、状态清单 | 交互设计 | 验证异常场景是否有出口 |
| 验证 | 可用性测试记录 | 可用性测试报告、录像 | 用研/测试 | 引用真实用户卡点作为问题证据 |
| 验证 | 启发式走查问题单 | 设计或产品自查 | 交互设计 | 补充测试未覆盖的规则类问题 |
| 验证 | 客服工单与埋点数据 | 客服系统、数据分析平台 | 产品/数据 | 佐证高频路径与已知痛点 |
材料缺失在评审中很常见，处理原则是标注而非跳过。缺少测试记录时，可用客服工单、访谈纪要或同类功能的埋点数据替代，并在评审记录中写明“替代依据”和证据强度；缺少异常态说明时，把该状态列为待补充项，评审中先按通用规则判断是否有出口。缺失项要写进结论，让后续决策者知道哪些判断基于较弱证据，避免把“没有证据”误读为“方案没问题”。
可用性评审按什么步骤执行
评审流程的价值在于把材料转化为可执行结论。建议按五步推进，每一步都明确输入、动作、输出和完成标志，避免会议开成方案宣讲。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确定范围与目标任务 | 核心任务清单、版本范围 | 圈定本次评审覆盖的任务与不覆盖项，指定每项任务的模拟用户 | 评审范围说明、任务走查清单 | 范围经产品负责人确认，任务数量与会议时长匹配 |
| 2. 材料预读与问题预判 | 依据清单中的全部材料 | 参会人提前阅读，各自提交预判问题，记录人合并去重 | 预判问题列表 | 会前问题已汇总，会议时间用于验证而非初次阅读 |
| 3. 任务走查与问题记录 | 原型、任务清单、预判问题 | 按任务逐步操作，记录卡点位置、现象与影响，现场不展开方案争论 | 原始问题记录 | 清单内每项任务均走查完毕，问题有位置和复现路径 |
| 4. 问题分级与整改分派 | 原始问题记录 | 按任务影响分级，指定责任人与期限，明确整改方式 | 可用性问题清单 | 每条问题有等级、责任人和期限 |
| 5. 复评与关闭 | 整改后的方案、问题清单 | 对阻断类和明显受阻类问题复走查，确认修复效果 | 复评记录、关闭结论 | 需复评的问题全部有结论，清单状态更新完毕 |
第3步是评审质量的关键。走查时要求操作者只描述“我做了什么、看到什么、卡在哪里”，把方案讨论留到记录之后，可以防止会议被最早提出的问题带偏。每项任务走查结束前，主持人应确认异常路径也被覆盖：操作失败、数据为空、权限不足时，界面是否给出明确出口。
第5步的复评范围要有取舍。阻断任务完成的问题必须复评；明显受阻的问题建议复评；体验瑕疵类问题可在记录中标注观察，随版本迭代处理。复评结论写入同一份问题清单，形成从发现到关闭的完整记录。
评审中角色如何分工与交付
可用性评审常见的失效形态是产品讲、其他人听。要避免这一点，每个参会角色都应带着交付物进入会议，并在会后留下明确产出。
| 角色 | 会前准备 | 会中职责 | 交付物 |
|---|---|---|---|
| 产品负责人 | 任务清单、业务规则说明、范围界定 | 解释任务背景与业务约束，裁定范围争议 | 评审范围说明、问题优先级确认 |
| 交互/视觉设计 | 原型、流程图、状态与文案说明 | 说明设计依据，现场回应走查中的路径疑问 | 设计说明、待修改设计项 |
| 研发代表 | 了解现有实现约束 | 反馈技术可行性与实现成本，指出方案中难以落地的交互 | 技术约束说明、实现风险项 |
| 用户研究或测试 | 测试记录、走查问题单、用户反馈 | 提供用户证据，核对问题是否与已有测试结论一致 | 证据引用说明、补充验证建议 |
| 记录人 | 问题记录模板 | 实时记录问题要素，会后整理分级清单 | 可用性问题清单 |
| 整改跟踪人 | 问题清单、责任人名单 | 会后跟进整改进度，组织复评 | 整改进度记录、复评结论 |
记录人与整改跟踪人可以由同一人兼任，但职责要分开写清楚：记录人保证问题不丢，跟踪人保证问题不悬空。研发代表的参与尤其重要，交互方案中依赖特定技术能力的部分，如果会上没有反馈，问题会在开发阶段才暴露，整改成本明显上升。
评审记录、问题清单和整改状态需要有承载的地方。使用 ONES 工作项管理评审问题时，可以把每条问题建成工作项，关联所属任务与原型说明文档，指定责任人与期限，整改完成后由跟踪人更新状态并附复评结论，评审记录与整改过程在同一处可追溯。这样复评时不必重新翻找会议纪要，问题从提出到关闭的链路清晰可见。
问题如何分级并形成整改清单
问题分级以任务影响为唯一口径，不以讨论激烈程度或修改成本为依据。建议分三档：阻断任务完成、明显受阻、体验瑕疵。分级结果直接决定整改优先级和是否复评。
| 等级 | 判断标准 | 处理要求 | 是否复评 |
|---|---|---|---|
| 阻断 | 用户无法完成核心任务，或异常状态下无任何出口 | 本版本必须修复，指定责任人与期限 | 必须复评 |
| 明显受阻 | 任务可完成，但需要绕行、反复尝试或依赖外部帮助 | 排入近期版本，明确整改方式 | 建议复评 |
| 体验瑕疵 | 不影响任务完成，表现为文案不清、间距不齐、提示不准确等 | 记录观察，随迭代处理 | 记录观察，不单独复评 |
每条问题按固定要素记录，保证清单可执行：位置（页面与具体控件）、任务（对应走查清单中的哪项任务）、现象（操作后看到什么）、影响（对任务完成的作用）、等级、整改建议、责任人、期限、状态。缺少“任务”要素的问题往往无法判断等级，记录人应在会上补齐。
整改清单形成后，跟踪人按期限检查进度，复评时对照原问题逐条确认修复效果。修复不彻底的问题重新打开，不另起新条目，保持同一问题的历史连续。体验瑕疵类问题在清单中保留观察状态，积累到一定数量后可作为下一轮设计优化的输入。
一个完整的评审示例
以下为演示情景，用于说明从依据到结论的过程，数据为示例设定。
场景与任务设定：某后台系统新增“批量导出报表”功能，目标用户为运营专员，日均使用约3次。本次评审覆盖两项核心任务：按条件筛选后导出、导出失败后重新发起。
依据材料引用：用户与任务依据来自运营岗位的任务清单和客服工单中“导出超时”的历史反馈；设计依据为交互流程图、可交互原型及空态与失败态说明；验证依据为上一版本同类功能的可用性测试记录，其中记录了筛选条件过多时用户放弃操作的现象。
走查发现的问题：其一，筛选条件超过五项时，导出按钮被折叠到页面底部，用户需滚动才能发现，测试记录中同类现象曾导致任务中断，定为阻断级；其二，导出失败提示仅显示“操作失败”，未说明原因和重试入口，定为明显受阻级；其三，导出成功提示停留时间过短，定为体验瑕疵级。
整改与复评结论：阻断级问题由交互设计在当周调整按钮位置并补充设计说明，明显受阻级问题由产品补充失败原因文案与重试按钮，体验瑕疵记录观察。复评时按原任务重新走查，前两项问题确认修复，清单状态更新为关闭；第三项保留观察，进入下一轮迭代清单。
评审完成后如何检查是否达标
一次评审是否做到位，不看会议是否顺利结束，而看依据、问题、整改三条线是否闭合。可用以下清单逐项核对。
- 依据材料是否齐备，缺失项是否标注替代依据与证据强度；
- 核心任务是否全部走查，异常路径是否覆盖；
- 每条问题是否具备位置、任务、现象、影响四项要素；
- 问题是否完成分级，阻断级与明显受阻级是否分派到责任人和期限；
- 需复评的问题是否完成复评，结论是否写入原问题条目；
- 评审记录、问题清单与复评结论是否归档，后续人员能否按任务或版本检索到。
核对中任何一项不满足，评审就还停留在“开过会”的状态。把这份清单作为评审收尾的固定动作，由整改跟踪人逐项确认后再宣布评审关闭，可以让可用性评审真正成为方案质量的把关环节，而不是一次性的讨论记录。
常见问题
没有做过可用性测试，还能组织可用性评审吗？
可以组织，但要在评审记录中说明证据强度。缺少测试记录时，可用客服工单、访谈纪要或同类功能的埋点数据作为替代依据，并标注“替代依据”及覆盖范围；缺少异常态说明时，把该状态列为待补充项，评审中先按通用规则判断是否有出口。关键是让后续决策者知道哪些结论基于较弱证据，避免把“没有证据”误读为“方案没问题”。
评审会上设计和研发对方案有分歧，应该当场定还是会后定？
建议按分歧性质分开处理。涉及任务范围、业务规则和优先级的分歧，由产品负责人在会上裁定，并写入评审范围说明；涉及技术可行性与实现成本的分歧，先记录研发反馈的约束条件和影响，会后由产品、设计、研发小范围确认整改方式，再更新问题清单。走查环节本身只记录现象，不展开方案争论，可以防止会议被最早提出的问题带偏。
体验瑕疵类问题要不要进整改清单？
要进清单，但处理方式不同。体验瑕疵不影响任务完成，通常记录为观察状态，随版本迭代处理，不单独安排复评。保留在清单里的价值在于积累：同类瑕疵积累到一定数量后，可以作为下一轮设计优化的输入。阻断级问题必须本版本修复并复评，明显受阻级问题排入近期版本并建议复评。
复评由谁组织，需要哪些人参加？
复评一般由整改跟踪人组织，参加人至少包括原问题的责任人和记录人，涉及技术实现的问题应请研发代表确认。复评范围按等级取舍：阻断级问题逐条重新走查原任务，明显受阻级问题确认修复方式是否生效，体验瑕疵类问题核对记录状态即可。复评结论写入原问题条目，修复不彻底的问题重新打开，不另起新条目，保持同一问题的历史连续。
评审记录和问题清单放在哪里，后续人员怎么查到？
核心要求是能按任务或版本检索到，并且问题状态与复评结论在同一处可追溯。常见做法是把每条问题建成工作项，关联所属任务与原型说明文档，指定责任人与期限，整改完成后由跟踪人更新状态并附复评结论。使用 ONES 工作项管理评审问题时，评审记录与整改过程可以在同一处查看，复评时不必重新翻找会议纪要。具体承载方式可按团队现有工具习惯确定。
