一次UI设计评审是否有效，可以用会后两个问题判断：团队知道哪些问题必须改吗？负责修改的人知道怎样才算改完吗？如果只留下“按钮大一点”“感觉不够高级”“再优化一下”，即使开了两个小时，也很难让下一版方案更接近目标。
这里用移动端订单确认流程，说明从会前准备到复核关闭的做法。它适合产品、设计、研发共同参与的交付前评审。整体项目节奏可以结合UI设计工作流程安排；本文只解决一场评审如何产生可执行结果，不把所有用户研究和方案探索都塞进同一次会议。
1. 先说明这次会议要作出什么决定
“看一下新版页面”太宽泛。可以改成“确认订单信息、修改地址和支付前检查三个步骤是否可以进入开发”。这句话同时限定了任务、范围和本次决策。颜色探索、下一季度的会员计划或其它页面的改版建议，除非影响当前任务，否则放入独立议题，避免不断扩散。
NN/g对设计评议的定义强调分析方案是否达到目标。评审因此应围绕工作及其效果展开，而不是评价设计师个人，也不是按参与者职位高低决定哪种颜色更好。提出意见时说明观察到的界面、受影响的任务和判断理由。
会前确定谁负责最终决策、谁记录、谁提供用户与业务证据、谁确认开发限制。小团队不需要为这些角色额外增加人数，但责任不能空着。支付或权限这类关键路径，还应邀请能解释服务端规则的人，防止前端画面通过之后才发现业务根本不允许这样处理。
2. 会前材料围绕任务，不用大段讲设计理念
准备一页简短说明：目标用户、当前任务、成功条件、已知约束和待决定问题。订单确认场景可以写成“用户核对商品、金额和收货信息，必要时修改地址，并明确知道何时会发起支付”。再附上任务入口和可点击原型，让参与者从同一个位置开始。
关键画面包括正常结果，也包括长商品名、优惠不可用、地址缺失、价格发生变化、网络失败与重复点击。真实数据不能直接用于评审时，可以用业务允许的测试数据构造这些边界。不要只给一张所有内容都最短、所有接口都成功的精致页面，那会把重要风险藏在设计稿之外。
版本也要明确。发一个固定评审入口，在文件中标记版本与日期，把尚未决定的备选方案放到单独区域。若会议中有人打开旧链接，应能立即看出来。评论落在旧画板还是新画板，可能直接决定后续修改是否做错对象。
3. 按用户任务走查，再进入界面细节
对一个范围较小的流程，可以先用五分钟介绍目标与约束，再用十分钟完整走查任务，接着十五分钟讨论问题，最后十分钟确认决策和责任。这是可调整的议程，不是所有项目必须采用的时间标准。复杂流程应拆成多场，不能靠无限延长会议解决。
走查时先不解释所有设计细节。让参与者尝试找到商品、核对总价、修改地址、返回确认并继续支付，记录他们停顿或误解的位置。之后再讨论为什么会这样。产品讲清规则，研发指出实现边界，设计说明备选与取舍；各方都应先定位问题，再提出解决建议。
然后检查系统反馈、术语一致性、撤销与恢复、错误预防等常见问题。NN/g可用性启发式原则可以作为提醒遗漏的检查框架，但不能把逐条打勾等同于用户已经能完成任务。会议走查发现的是待验证风险，需要用户研究的疑问应单独记录。
4. 把意见改写成有证据的问题卡
“按钮不明显”可以改写为：“订单页底部有三个同等强调的按钮，用户无法判断哪一个会发起支付。需要明确主要操作与返回操作，验收时能正确说明每个按钮的后果。”这样的记录保留了观察和目标，也给设计师留下寻找解决方案的空间。
每张问题卡至少填写以下内容：位置或画板链接；用户任务；实际问题；证据与不确定性；影响范围；负责人；处理决定；验收条件。证据可以是研究观察、已知业务规则、规范要求或可重现的实现问题。个人偏好也可以提出，但应明确它是偏好，不能伪装成用户结论。
一个可直接使用的例子是：“订单确认页，快速连续点击提交会发出两次请求；风险是重复创建订单；由研发确认幂等机制，设计补充处理中反馈；验收时连续操作只形成一条业务记录，失败后保留订单信息并能安全恢复。”这条问题卡同时分清了交互设计和技术处理的责任。
对于颜色和字号问题，也应写出具体条件。不要只写“提升可读性”，而要指出哪段文字、什么背景、当前结果与适用要求。可以附上对比度检查记录，让下一轮审阅者能够用同样方式复核。
5. 按影响和发生条件分级，不按谁声音大排序
NN/g关于严重程度的讨论考虑问题出现频率、造成的影响和持续性。实际项目可以据此建立自己的优先级，不必照搬数字标签。先判断是否阻断核心任务、是否可能造成损失，再考虑发生范围与恢复成本。
- 发布前解决：核心操作无法完成、可能产生错误订单、重要信息丢失，或用户无法获知关键后果。
- 本轮优先处理：任务能完成，但用户需要明显绕行、重复输入，或容易误解业务规则。
- 进入改进计划：不影响完成任务的样式不一致、次要信息层级和体验细节。
这三类是本流程的工作约定，不是通用行业认证。一个边框颜色问题在装饰卡片里可能轻微，在唯一识别输入框的位置就可能影响任务。相反，一个视觉上很醒目的排版问题，如果并不造成使用障碍，也不应自动排在支付风险之前。
发生频率未知时，不要随手写“低频”来降低优先级。记录未知项、验证负责人和期限。例如“海外手机号被拒绝的占比未知，需检查服务覆盖范围和真实错误记录”。小流量场景也可能有严重影响，频率与影响应分别讨论。
6. 区分决定、实验与暂缓，防止评论无限循环
每个议题结束时，给它一个明确结果：采用方案A并记录原因；补充证据后再决定；或暂缓并说明条件。不能把“再看看”同时当成通过和不通过。如果没有足够证据支持某种布局，可以安排一次小范围任务测试，说明要观察的行为，而不是让设计师继续凭感觉改十版。
暂缓事项也需要说明代价。比如本次先保留旧地址选择器，但需要确认不会丢失已选地址，并记录下次改版的触发条件。不要把所有非阻断问题都无限放进“后续优化”，却没有负责人与回访日期。迭代结束时应能区分已解决、已接受风险和未完成问题。
会议记录最好同时保留原问题和最终决定。若只留下新截图，后来的人无法知道为何去掉一个按钮，也难以判断新需求是否推翻了当时的约束。产品变化可以改变决定，但应该基于新的条件，而不是重新重复一次无上下文的争论。
7. 用同一份设计文件完成定位与复核
在Pixso里把正常流程与异常状态放在同一评审区域，用评论锚定具体界面位置，并通过@成员明确跟进对象。官方可视化评论说明介绍了在评论中加入图片等信息的方式，适合附上错误位置或前后差异。方法是否奏效，关键仍是评论写得具体并且有人处理。
修改完成后不要只回复“已改”。附上更新位置、采用的方案和对应验收结果，由问题提出者或指定审阅者复核。若涉及网络失败、空数据或权限，结合页面状态分类确认同一套规则没有遗漏其它分支。需要真实接口才能验证的项目，明确留到开发验收，不要在静态设计阶段提前标完成。
8. 散会前确认这六项输出
- 本次评审的流程范围和固定版本入口。
- 已经通过的部分，以及通过所依据的约束。
- 必须修改的问题、优先级、责任人和完成时间。
- 需要补充证据的疑问，以及具体验证方法。
- 暂缓事项的原因、风险和重新讨论的条件。
- 每个修改项的验收方式与复核人。
下一次会议从上一轮问题的结果开始，而不是重新从第一页逐张讲解。团队逐渐积累的将是一套可以追溯的设计判断：哪些变化解决了问题，哪些假设仍未证实，哪些边界需要继续关注。这样的评审才会持续改善交付，而不是把讨论次数当成质量本身。
