产品原型评审要聚焦可用性并形成闭环，关键在于把“看图提意见”改成围绕关键任务的可验证流程：评审前定清目标用户、任务脚本和原型范围，评审中按任务走查并记录卡点证据，评审后把问题转成带负责人和验收标准的工作项，修改原型后复验再关闭。本文给出可直接照做的准备清单、会议步骤、闭环台账、角色分工表、完整示例和完成检查表，适用于产品经理或设计负责人组织单次原型评审并跟踪到问题关闭。
要点总览（TL;DR）
- 评审前把目标用户、3–5个关键任务、原型可点击范围和不讨论范围写成书面清单，讨论对象从“页面好不好看”转为“任务能否完成”。
- 评审中由主持人按任务脚本逐个推进，操作者实际点击原型，观察者先记录卡点和停顿，任务结束后再讨论，问题当场标注阻断、影响效率、体验优化三级。
- 评审后每条问题转成带关联任务、现象、分级、负责人、验收标准的工作项，按“提出—分派—修改—复验—关闭”推进，未关闭项固定跟踪。
- 验收标准写成可观察的用户行为，例如“无需提示15秒内找到发票入口”，复验时由原操作者按同一任务脚本再走一遍，直接判断通过与否。
- 用角色分工表和完成检查表收口：阻断项未分派或复验未通过且无处理计划时，安排补充走查或重新分派。
评审前先定清楚：评什么、谁来评、用什么原型
评审会发散，多数时候源于准备阶段没有约定讨论对象。启动前需要产出一份评审准备清单，把目标用户、关键任务、原型可点击范围、参会角色和记录方式固定下来，让现场讨论有明确边界。
明确目标用户、核心任务与不讨论范围
先写清本次原型面向哪类用户、他们要在原型上完成哪几件事。关键任务控制在3–5个，每个任务写成“用户身份＋目标＋起点＋完成标志”的形式，例如“首次下单的企业采购员，从商品详情页完成一笔含发票信息的订单提交”。同时列出本次不讨论的范围，通常包括视觉风格细节、文案润色、需求范围增减和后台实现方案，这些问题另记另议，不占用评审主线。
选择原型保真度与可点击范围
原型保真度按本次要验证的问题选择：验证流程是否走得通，用可点击的中低保真原型即可；验证信息理解与表单填写，需要接近真实的内容和字段；验证视觉与品牌感受，才需要高保真稿。准备时附一份可点击范围说明，标明哪些页面可跳转、哪些是占位、哪些异常分支尚未制作，避免参会者把未制作部分当成设计缺陷。
确定参会角色与分工
一次评审建议包含主持人、记录人、设计者、研发代表、业务或用户代表。主持人负责按任务推进和控制提问方式；记录人负责把卡点对应到任务、现象和影响；设计者负责演示原型并解释设计意图，会上不急于辩护；研发代表关注实现可行性与技术约束；业务或用户代表以真实使用者视角操作原型。人数控制在6–8人，角色齐全比人数多更重要。
准备任务脚本与观察记录表
任务脚本给操作者看，只写任务目标和使用情境，不写操作步骤提示。观察记录表给记录人用，建议包含任务编号、时间点、操作者动作、停顿或误操作、口头反馈、影响判断和截图位置。两张表在会前发给参会者，让大家知道现场要产出什么。
准备阶段完成标志：目标用户与3–5个关键任务已书面确认，原型链接和可点击范围说明可访问，角色分工表已通知到人，任务脚本与观察记录表已就绪。
评审会怎么开：按任务走查，把意见变成可用性证据
会议执行的核心规则是“按任务走查、先观察后讨论”。主持人按任务脚本逐个推进，操作者实际点击原型，其他人先观察记录，任务结束后再集中讨论。这样得到的反馈带有具体任务和操作证据，便于后续判断严重程度。
开场说明规则
用两三分钟说明本次评审的目标、任务清单、不讨论范围和记录方式，并明确一条现场纪律：先让操作者完成任务，观察者记录卡点和停顿，任务结束后再提问和讨论。提前说明可以显著减少中途插话和方案争论。
逐任务执行与观察记录
每个任务开始前，主持人向操作者宣读任务脚本，不提示入口位置。操作过程中，记录人按观察记录表记下三类信息：操作者在哪一步停顿或犹豫、出现了什么误操作或回退、操作者说了什么。设计者和研发代表此时只记录，不打断。一个任务结束后，主持人先请操作者复述自己的理解和期望，再开放讨论。
提问方式
提问围绕事实和期望展开，例如“刚才这一步你在找什么”“你预期点击后会发生什么”“这个提示你理解成什么意思”。避免直接问“你觉得这里改成按钮好不好”，这类问题会把讨论引向方案偏好。操作者提出的改进建议照实记录，会上不展开评审。
现场分级与发散控制
每个卡点当场标注初步分级，便于会后排期。建议使用三类：阻断，指任务无法完成或产生严重误解；影响效率，指任务能完成但路径绕、反复试错或信息缺失；体验优化，指不影响完成但影响感受和顺畅度。视觉细节、文案措辞和需求范围问题记入“另议清单”，由主持人在任务间隙统一收口，不占用走查时间。
| 分级 | 判定标准 | 现场处理 |
|---|---|---|
| 阻断 | 任务无法完成，或操作者产生会导致错误结果的误解 | 当场确认复现步骤，标记为最高优先级 |
| 影响效率 | 任务可完成，但存在明显绕行、反复试错或关键信息缺失 | 记录现象与影响，会后评估合并处理 |
| 体验优化 | 不影响任务完成，涉及顺畅度、提示语气、布局观感 | 记录后合并处理，不逐条排期 |
会议结束前，主持人用五分钟复述本次发现的阻断项和影响效率项，确认记录人与操作者的理解一致，并约定反馈整理和复验的时间点。
反馈怎么变成可跟踪的闭环
评审记录只有转成带负责人、优先级和验收标准的工作项，才具备被跟踪的条件。闭环的基本路径是“提出—分派—修改—复验—关闭”，每个状态都要有明确的责任人和完成标志。
问题转工作项的字段
每条问题转成一条工作项，至少包含以下字段：问题编号、关联任务、现象描述（操作者做了什么、发生了什么）、影响判断、分级、负责人、期望结果、验收标准、原型截图或时间点。验收标准要写成可观察的结果，例如“新用户在无提示情况下能在30秒内找到发票信息入口并完成提交”，避免写成“优化发票入口”。
分派与排期
阻断项在评审当天完成分派，进入当前迭代优先处理；影响效率项按任务影响面排序，可合并同类问题一次修改；体验优化项汇总后批量处理。分派时明确设计者负责原型修改、产品经理负责需求口径确认、研发代表负责可行性反馈，避免一条问题多人负责却无人推进。
修改后的二次验证与关闭
原型修改完成后，由原操作者或同类用户代表按同一任务脚本再走一遍，重点验证原卡点是否消失、是否引入新的理解障碍。复验结论写入台账，通过则关闭，未通过则退回修改并记录原因。二次验证不必开完整评审会，按任务做一次简短走查即可。
状态流转与未关闭项跟踪
台账状态建议设为待确认、已分派、修改中、待复验、已关闭、挂起。挂起项需写明原因和计划处理时间。未关闭项在下次原型评审或团队周会中固定过一遍，超过约定时间未处理的阻断项升级给项目负责人。评审结束后做一次简短复盘，记录本次哪些任务脚本设计得好、哪些问题分级有争议，用于改进下一次评审。
反馈闭环需要工作项状态和责任人持续可见。ONES 可用于承载这类工作项流转：把评审问题登记为工作项，关联所属任务与原型说明，设置负责人、优先级和状态，在修改与复验之间推进状态变化，让未关闭项在列表中保持可查。工具承担的是记录与流转，评审规则和验收标准仍需团队自己约定。
角色与交付物分工表
下表把各角色在评审前、中、后的职责和产出放在同一口径下对照，便于会前分工和会后追责。
| 角色 | 评审前 | 评审中 | 评审后 | 主要交付物 |
|---|---|---|---|---|
| 产品经理/设计者 | 确认目标用户与关键任务，准备可点击原型和范围说明 | 演示原型，解释设计意图，记录但不急于辩护 | 确认需求口径，完成原型修改，提交复验 | 任务脚本、原型链接、修改后的原型 |
| 主持人 | 制定评审规则，确认参会角色，准备任务脚本 | 按任务推进，控制提问方式，收口另议问题，组织现场分级 | 组织复验安排，主持简短复盘 | 评审议程、现场分级结论、复盘记录 |
| 记录人 | 准备观察记录表 | 记录卡点、停顿、误操作与口头反馈，标注任务与时间点 | 整理问题清单，录入闭环台账 | 观察记录表、问题清单、闭环台账 |
| 研发代表 | 了解原型范围与技术约束 | 观察操作过程，记录实现可行性问题 | 对相关工作项给出可行性反馈 | 技术约束说明、可行性意见 |
| 业务/用户代表 | 确认任务情境是否符合真实使用场景 | 按任务脚本操作原型，复述理解与期望 | 参与二次验证，确认原卡点是否消除 | 操作反馈、复验结论 |
交付物的完成时点建议统一：任务脚本和角色分工在评审前一个工作日发出，观察记录表和问题清单在评审当天完成整理，闭环台账在评审后一个工作日内建好，复验结论在原型修改完成后三个工作日内回填。
一个完整示例：下单流程原型评审怎么走一遍
以下为演示情景，用于说明流程如何落地，不对应具体企业案例。
背景与关键任务设定
某企业采购系统的下单流程改版，原型为可点击中保真稿。目标用户为首次使用系统的小微企业采购员。本次设定三个关键任务：从商品列表找到指定办公用品并加入购物车；在结算页填写发票信息并提交订单；订单提交后确认订单状态和预计到货时间。不讨论范围包括页面配色、按钮圆角和后台库存扣减逻辑。
评审中的典型问题与记录方式
任务一进行顺利。任务二中，操作者在结算页停留约40秒，先后点击“备注”和“配送方式”，最后才在页面底部找到发票信息入口，口头反馈“以为发票要在提交后填”。记录人记为：任务二，时间点02:15，现象为反复寻找发票入口并误点其他区域，影响为结算时间延长且存在漏填风险，初步分级为影响效率，附截图。任务三中，操作者提交后看到“订单已受理”提示，无法判断是否成功，反复刷新页面，记为阻断级问题。
转工作项、修改与复验关闭
会后两条问题分别建为工作项。发票入口问题关联任务二，负责人为设计者，验收标准为“新用户在结算页无需提示可在15秒内找到发票信息入口”，状态为已分派。订单状态问题关联任务三，负责人为设计者与产品经理共同确认提示文案和状态展示，验收标准为“提交后页面明确显示订单号、当前状态和预计到货时间”，状态为已分派。修改完成后，邀请原操作者按同一任务脚本复验：发票入口调整到结算页首屏，操作者一次找到；订单提交后状态信息完整显示，原卡点消除。两条工作项复验通过后关闭，台账记录复验时间和结论。
可迁移的规律
这个示例体现三点：任务脚本让问题定位到具体步骤，而不是笼统的“结算页不好用”；记录现象和影响，使分级有依据；验收标准写成可观察的用户行为，复验时能直接判断通过与否。换到其他流程，只需替换任务内容和验收标准，流程结构保持一致。
完成检查：这次评审算不算做到位
评审结束后，按下表逐项核对，全部通过才算完成一次有效评审；出现阻断项未关闭或关键记录缺失时，安排返工。
| 阶段 | 检查项 | 通过标准 |
|---|---|---|
| 准备 | 任务脚本 | 3–5个关键任务，含用户身份、目标与完成标志，会前已发出 |
| 准备 | 角色与原型 | 五个角色均有对应人员，原型链接可访问，可点击范围说明明确 |
| 会议 | 按任务走查 | 每个任务均由操作者实际完成，观察者先记录后讨论 |
| 会议 | 记录与分级 | 每个卡点对应任务、现象、影响和分级，截图或时间点可追溯 |
| 闭环 | 工作项字段 | 问题均已转为工作项，负责人、验收标准和状态齐全 |
| 闭环 | 复验与跟踪 | 阻断项和影响效率项完成复验并有结论，未关闭项有责任人和计划时间 |
返工条件建议明确两条：存在未分派的阻断项，或阻断项复验未通过且无新的处理计划。出现任一情况，主持人在三个工作日内组织补充走查或重新分派，并将结果回填台账。完成检查表与闭环台账一起归档，作为下一次评审的基线。
常见问题
评审会上有人坚持讨论配色和文案，主持人怎么处理？
把这类意见记入“另议清单”，由主持人在任务间隙统一收口，不占用走查时间。开场时已说明不讨论范围，此时只需重申边界：本次验证的是任务能否走通、信息是否被理解，视觉与文案在原型定稿前另行处理。若某条视觉意见实际影响了操作者找到入口，就把它转写成可用性问题记录，例如“按钮与背景对比不足导致入口未被发现”，再按分级处理。
没有真实用户到场，用内部同事代替操作者，评审结论还可信吗？
内部同事可以操作原型，但需要说明其代表性限制。选择对业务场景不熟悉的同事，避免由需求提出者本人操作；任务脚本只给目标不给路径；记录时区分“熟悉系统的同事”和“目标用户”的差异。内部走查适合发现流程阻断和理解障碍，涉及真实使用习惯和信息需求的结论，应在有条件时用目标用户补充验证。复验环节同样优先邀请原操作者或同类用户参与。
原型还在频繁改动，每次改完都要重新组织完整评审吗？
不必每次开完整评审会。完整评审用于阶段性验证关键任务；局部修改后按任务做一次简短走查即可，由原操作者或同类用户代表按同一任务脚本复验原卡点是否消失、是否引入新的理解障碍。只有改动涉及任务路径、核心信息结构或新增关键页面时，才需要重新组织多人评审。复验结论回填台账，与原问题关联，保持记录连续。
问题分级在现场有争议，怎么避免排期时反复拉扯？
把分级依据落在现象和影响上，而不是个人判断。记录时写清操作者做了什么、卡在哪一步、是否导致任务无法完成或产生错误结果，分级自然有据可依。现场先给初步分级，会后由主持人和产品经理按影响面复核，争议项以“是否阻断任务完成”为第一判断标准。体验优化类问题汇总后批量处理，不逐条排期，可以减少分级讨论占用的时间。
评审问题登记到工具里之后，怎么保证不会长期挂着没人管？
关键是让未关闭项保持可见并有明确责任人。工作项设置负责人、优先级和状态，状态按待确认、已分派、修改中、待复验、已关闭、挂起流转，挂起项写明原因和计划处理时间。未关闭项在下次原型评审或团队周会中固定过一遍，超过约定时间未处理的阻断项升级给项目负责人。ONES 可用于承载这类工作项流转，把评审问题关联所属任务与原型说明，让修改与复验之间的状态变化保持可查；评审规则和验收标准仍需团队自行约定。
