产品可用性评审把原型或方案交给目标用户和跨职能角色，按预设任务实际操作，记录卡点与疑问，再形成可追踪的改进项并安排复评。本文按启动准备、现场执行、角色分工、问题落地、完整示例和收尾检查的顺序展开，覆盖产品方案沟通与验证范围内的可用性评审，视觉设计制作细节和需求质量本身的评审不在本篇展开。
要点总览（TL;DR）
- 可用性评审启动前先锁定三件事：评审对象与版本、任务脚本、通过口径，三者写进一页启动单，评审结果才有对照依据。
- 任务脚本按目标用户角色、起始状态、要完成的操作、成功判据四要素书写，一场评审准备3到6个任务，覆盖核心流程和易错环节。
- 评审当天先完整收集观察记录，当场不下结论；任务结束后再追问原因，避免中途引导参与者。
- 问题按严重程度与出现频次归类，改进项写清现象、影响、建议方向、负责人和目标版本，并安排复评范围与验证方式。
- 收尾以改进项有负责人和目标版本、复评已排期、记录已归档为硬性条件，评审才能从一次会议变成可追踪的改进循环。
可用性评审先定什么：对象、任务与通过口径
评审启动前需要先确定三件事：评什么版本、让参与者做什么、达到什么结果算通过。这三项没有定清楚，现场容易变成自由浏览，事后也无法判断问题是否严重、改进是否生效。建议在评审前填写一份启动单，作为组织者、参与者和决策人共同确认的输入。
评审对象：锁定版本与覆盖流程
评审对象可以是静态原型、方案稿，也可以是可交互版本。无论哪种，都要写明版本号或文件标识，并列出本次覆盖的流程范围，例如“下单流程：商品详情页进入—选择规格—填写地址—提交订单—支付结果页”。范围之外的页面本次不评，避免参与者在无关页面上消耗时间。如果原型在评审前有改动，需要更新版本标识并通知参与者，保证记录中的问题能对应到具体版本。
任务脚本：四要素写法
任务脚本描述参与者要完成的事情，按四要素书写：目标用户角色、起始状态、要完成的操作、成功判据。只写功能名称（如“测试购物车”）无法指导现场操作，也无法判断任务是否完成。示例如下：
- 目标用户角色：首次在该平台下单的普通消费者；
- 起始状态：已登录，购物车中有一件商品，收货地址为空；
- 要完成的操作：从购物车进入结算，新增一个收货地址并提交订单；
- 成功判据：订单提交成功并看到支付入口，全程无需外部提示。
一场评审通常准备3到6个任务，覆盖核心流程和容易出错的环节。任务之间可以有关联，但每个任务都要有独立的成功判据，便于分别统计完成情况。
通过口径：提前约定判定方式
通过口径回答“这次评审结果怎么算”。常用三个观察维度：任务完成率（按任务分别统计完成人数与参与人数之比）、关键卡点（导致任务中断或需要提示才能继续的问题）、严重问题数量（按事先定义的严重程度分级计数）。具体阈值由团队根据产品阶段自行设定，例如早期原型可以接受较低完成率，重点看卡点分布；临近上线的版本则对严重问题数量更敏感。阈值写进启动单，评审结束后直接对照，避免事后各说各话。
启动单：一页纸的输入清单
| 项目 | 填写内容 |
|---|---|
| 评审对象与版本 | 原型或可交互版本名称、版本号、覆盖流程 |
| 任务脚本 | 每个任务的角色、起始状态、操作、成功判据 |
| 参与角色 | 目标用户或业务代表人数、产品、设计、研发、决策人 |
| 通过口径 | 任务完成率统计方式、卡点定义、严重问题分级与阈值 |
| 不纳入范围 | 视觉细节、文案润色、需求本身的合理性 |
评审执行步骤：从任务脚本到问题记录
评审当天的目标是完整收集观察，而不是当场得出结论。组织者按固定顺序推进，记录人同步填写记录表，参与者专注于完成任务和表达真实感受。
开场说明
开场用两三分钟说明评审目的：检验方案是否好用，参与者是在帮助发现问题，操作中的任何停顿和疑问都是有价值的信息。明确告知不评判设计者个人，也不要求参与者“表现得好”。同时说明记录方式，征得同意后开始。
逐任务观察
每个任务由参与者独立操作，组织者朗读任务脚本后不再提示。记录人重点记录四类现象：操作路径（点了哪些入口）、停顿（在哪里停留超过预期时间）、误操作（点错、返回、重复填写）、口头疑问（“这里是什么意思”“点这个对吗”）。记录时写现象本身，例如“在地址填写页停留约40秒，两次点击返回修改手机号”，不写“地址页设计不好”这类判断。
提问方式
任务进行中保持安静，避免引导。任务结束后再追问原因，问题以开放为主：“刚才在地址页你停顿了一下，当时在想什么？”“你期望点提交后发生什么？”避免“是不是因为按钮不明显”这类带答案的提问，否则记录到的是组织者的猜测而非参与者的真实判断。
记录表字段
| 字段 | 填写说明 |
|---|---|
| 任务编号 | 对应任务脚本编号，如T1、T2 |
| 现象 | 客观描述操作、停顿、误操作或原话 |
| 位置 | 页面或步骤名称 |
| 严重程度 | 按事先分级填写，如阻断、严重、一般、建议 |
| 复现条件 | 参与者角色、设备、起始状态等 |
| 参与者编号 | 匿名编号，便于统计同一问题出现次数 |
当场不做结论，也不急着讨论解决方案。所有任务跑完后，再集中归类，这样能看清同一问题在不同参与者身上重复出现的频次。
角色分工与各自交付物
可用性评审常见的问题是变成产品经理的单向演示：参与者看一遍，点头通过，问题没有被记录。按角色明确职责和交付物，可以让评审保持验证性质。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 组织者 | 准备启动单与任务脚本、控场、汇总记录 | 启动单、原始观察记录表、评审小结 |
| 产品与设计角色 | 开场说明方案意图，现场只记录不辩护 | 方案背景说明、对问题的补充解释（会后） |
| 目标用户或业务代表 | 按脚本操作，表达真实判断与疑问 | 操作过程与口头反馈 |
| 研发角色 | 评估改进项的实现代价与依赖 | 代价评估意见、依赖说明 |
| 决策人 | 确认改进项优先级与复评时间 | 优先级结论、复评排期 |
产品与设计角色在现场容易忍不住解释“这里其实是这样的”，这类解释会掩盖真实卡点。可以约定：现场只记录，会后统一回应。研发角色不必全程参与操作观察，但应在归类阶段到场，对改进项的实现代价给出判断，避免排出无法落地的优先级。决策人的作用是在归类结束后当场确认哪些改进项进入目标版本、哪些延后，以及复评安排。
问题归类与改进项落地
原始记录是一堆现象，改进项才是可以分配和验证的工作。归类的过程是把现象合并、分级、定性，再写成有人负责、有目标版本的条目。
按严重程度与频次归类
先按严重程度分组：阻断任务完成的问题优先，其次是导致明显绕路或反复操作的问题，再次是影响体验但不妨碍完成的问题。同一现象被多名参与者触发时标注频次，频次高的中等问题往往比偶发的严重问题更值得优先处理。归类结果用一张问题清单呈现，每个问题关联对应的记录行。
区分三类问题
- 方案问题：流程设计、信息层级、交互方式导致的操作困难，需要通过改方案解决；
- 信息缺失问题：页面缺少必要说明、状态提示或错误反馈，补充信息即可改善；
- 操作习惯问题：参与者按以往经验操作产生的偏差，需要判断是方案不符合预期，还是参与者不熟悉场景。
三类问题的处理方式不同，混在一起会导致改进项写得含糊。归类时给每个问题标注类型，后续分配负责人时更有针对性。
改进项写法
每条改进项包含五个要素：现象（引用记录中的客观描述）、影响（对任务完成或理解的具体影响）、建议方向（改什么，不必写到像素级）、负责人、目标版本。示例：“T2地址填写页，3名参与者在手机号输入后未发现格式错误提示，提交时才被拦截；影响：增加一次返工；建议方向：输入时即时校验并提示；负责人：设计角色；目标版本：V1.2。”
与工作项关联并安排复评
改进项需要进入团队日常的任务跟踪，与对应的需求或任务工作项建立关联，这样在版本推进中能查到每条改进项的状态，复评时也有据可依。在 ONES 中，可以把改进项作为工作项登记，关联到对应的需求条目，记录负责人、目标版本和状态，复评时按关联关系逐条核对是否已处理。复评范围按改动大小确定：只改了局部页面，就复评相关任务；流程结构有调整，则重跑全部任务脚本。复评的验证方式与首次评审一致，用同一套任务脚本和成功判据对照。
示例：一次下单流程原型的可用性评审
以下为演示情景，用于说明从脚本到改进项的完整过程，数据为示例，不代表真实项目结论。
场景设定
某电商产品对下单流程原型做可用性评审，邀请5名目标用户参与，产品、设计、研发各1人到场，决策人在归类环节参加。评审对象为可交互原型V0.9，覆盖商品详情、规格选择、地址填写、订单提交四个步骤。
任务脚本与典型卡点
任务T1：从商品详情页选择规格并加入购物车，成功判据为购物车数量更新。任务T2：从购物车进入结算，新增收货地址并提交订单，成功判据为看到支付入口。任务T3：在提交前修改收货地址，成功判据为订单页地址同步更新。
观察到的典型卡点：T2中3名参与者在手机号格式错误时未看到即时提示，提交后才被拦截返回修改；T1中2名参与者在规格选择区未注意到“已选规格”的汇总信息，反复上下滑动确认；T3中1名参与者修改地址后未返回订单页核对，直接提交，事后才发现地址未同步。
记录表填写样例
| 任务编号 | 现象 | 位置 | 严重程度 | 复现条件 | 参与者编号 |
|---|---|---|---|---|---|
| T2 | 手机号格式错误无即时提示，提交时被拦截并返回修改 | 地址填写页 | 严重 | 首次下单用户，移动端 | P1、P3、P5 |
| T1 | 未注意已选规格汇总，反复滑动确认选择结果 | 商品详情页规格区 | 一般 | 多规格商品 | P2、P4 |
| T3 | 修改地址后未返回订单页核对即提交 | 地址修改页至订单页 | 严重 | 提交前修改地址 | P3 |
归类后的改进项与优先级
- 改进项1：地址填写页增加手机号即时校验与错误提示。类型为信息缺失，频次3人，优先级高，负责人为设计角色，目标版本V1.0。
- 改进项2：规格选择区强化已选规格的汇总展示。类型为方案问题，频次2人，优先级中，负责人为设计角色，目标版本V1.1。
- 改进项3：地址修改后返回订单页时给出地址已更新的明确提示。类型为信息缺失，频次1人但影响提交结果，优先级高，负责人为产品角色，目标版本V1.0。
复评验证
V1.0发布前安排复评，范围限定在T2和T3两个任务，邀请3名新的目标用户，使用同一套成功判据。验证点为：手机号错误时是否在输入阶段看到提示；修改地址返回后是否注意到更新提示。复评记录与首次记录对照归档，作为该版本可用性改进的凭据。
完成检查：这场评审算不算做完
评审结束不等于做完。用下面这份清单逐项核对，全部满足才算闭环。
- 任务脚本覆盖了本次核心流程，评审对象有明确的版本标识，记录中的问题能对应到该版本；
- 每条问题都有客观现象、所在位置和严重程度，没有只写结论的条目；
- 改进项写明了现象、影响、建议方向、负责人和目标版本，并已与对应的工作项建立关联；
- 决策人已确认改进项优先级，复评时间已排期，复评范围和验证方式已写明；
- 启动单、原始记录表、问题清单和评审小结已归档，可供下次评审对照版本变化。
如果改进项还没有负责人或目标版本，说明归类环节没有走完；如果复评没有排期，改进是否生效就无法验证。把这两项作为收尾的硬性条件，可用性评审才能从一次会议变成可追踪的改进循环。
常见问题
可用性评审邀请多少名目标用户比较合适？
数量取决于评审目的和产品阶段。原型早期重点发现明显卡点，邀请5名左右目标用户通常能暴露主要问题；临近上线需要验证改进是否生效，复评可以只邀请3名新用户，聚焦改动过的任务。参与者不必多，但角色要与任务脚本设定的目标用户一致，否则记录到的操作偏差难以判断是方案问题还是场景不匹配。
评审现场参与者一直问“这个按钮是干什么的”，要不要回答？
任务进行中先不回答，把疑问原样记录下来，这本身就是信息缺失的信号。等任务结束后再追问：“你当时看到这个按钮，期望它做什么？”如果多名参与者在同一位置提出类似疑问，归类时应优先考虑补充说明或调整文案。现场直接解释会掩盖卡点，也会让后续参与者失去独立判断的机会。
改进项改完之后，复评要重跑全部任务吗？
按改动范围决定。只调整了局部页面或提示文案，复评相关任务即可；流程结构、步骤顺序有调整，则重跑全部任务脚本。复评使用与首次评审相同的任务脚本和成功判据，邀请新的目标用户参与，记录表沿用同一套字段，这样两次记录可以直接对照，判断改进是否真正生效。
团队没有专职可用性研究人员，谁来组织评审？
组织者可以由产品经理或设计师兼任，关键是职责分开：组织者负责准备启动单与任务脚本、控场和汇总记录，方案的设计者在现场只记录不辩护。研发角色在归类阶段到场评估实现代价，决策人确认优先级和复评时间。角色少的时候一人可以承担多项职责，但“设计者现场不解释”这条约定要保留，否则评审容易退化成方案宣讲。
评审发现的问题很多，怎么决定先改哪些？
先看是否阻断任务完成，阻断类问题优先；再看出现频次，多名参与者重复触发的中等问题通常比偶发的个别问题更值得先处理。归类时区分方案问题、信息缺失问题和操作习惯问题，处理方式不同。优先级最终由决策人在归类结束后确认，同时明确哪些改进项进入目标版本、哪些延后，避免清单越积越长却无人推进。
