UI设计评审应围绕真实任务，而不是逐像素挑错。先确认页面层级是否支持主要目标，再检查默认、悬停、禁用、加载、错误和无权限状态，最后核对可读性、触控和研发实现条件。评审结论要能回到具体页面、组件和负责人。
用墨刀设计把订单详情页和状态变体放在同一份文件，按“查看订单—修改地址—提交失败—恢复”走查。产品、设计和研发看到的是同一版本，讨论会更容易落到证据。
评审前先约定“今天要做哪一个决定”
一次评审可以决定订单地址修改流程是否交付研发，也可以决定新的表格组件能否进入组件库，但不宜同时要求所有人讨论品牌风格、业务范围和像素细节。发出邀请时附上目标任务、版本链接、角色权限、已确认规则以及尚未决定的问题，让与会者知道哪些可以改、哪些需要另开业务讨论。
以订单详情页为例，先固定规则：未发货时允许修改收货地址，已发货时提供售后联系入口；保存失败保留输入，保存成功回到详情并更新地址。评审材料至少展示未发货、已发货、编辑中、字段错误、保存中和保存失败。只有默认成功页面，很难判断这个方案是否完整。
产品负责人解释为什么要改和业务边界，设计师带大家走界面，研发指出数据与实现约束，一人记录决议。不要让讲解者边演示边记每条意见；也不要把“所有人都没有反对”当成已经确认业务规则。
四层检查从任务开始
| 层次 | 要问的问题 | 证据 |
|---|---|---|
| 信息层级 | 用户能否一眼找到主任务和当前状态？ | 标题、主按钮、状态标签 |
| 组件状态 | 等待、失败、禁用和无权限是否可区分？ | 状态变体和触发条件 |
| 交互反馈 | 操作后是否知道成功、处理中或需修正？ | 提示位置、可撤销性、返回路径 |
| 可用性与交付 | 文字、对比度、点击区和标注是否可实现？ | 长文案样例、尺寸、变量和说明 |
视觉层级：先找主任务，再看细节
在订单详情中，订单状态、物流进度、收货地址和售后入口的优先级并不相同。检查标题与正文、主要按钮与文本操作、警告与普通说明能否被区分；再检查同类信息的字体、间距和对齐是否一致。某个按钮很醒目不代表层级正确：已发货时仍把“修改地址”做成主要按钮，会让视觉强调与业务规则冲突。
用真实长度的商品名、姓名和地址替换占位文本。试一条两行商品名、一个较长收货地址和三位数金额，观察关键状态是否被挤走、操作是否换行、弹窗是否遮住确认按钮。页面在空数据、单条和多条内容下都要能读，不能只评审最整齐的一组样例。
交互与状态：把每次点击的去向问到底
点击编辑后焦点落在哪里，取消后回到哪里；保存中能否再次点击；失败后哪些输入保留；用户退出编辑时如何处理未保存内容，都应有明确答案。禁用、加载和无权限也不能只靠按钮变灰区别，否则用户无法知道是等待、缺少输入还是没有操作资格。
特别关注不可见的成功：如果保存后只弹一条短暂提示，详情地址却没更新，用户会怀疑操作失败。成功反馈最好同时体现在任务对象上，例如新地址出现在详情中；失败提示则靠近问题字段或当前操作区，并给出下一步。关闭提示本身不应丢失已填地址。
可用性：对比度要测，点击区不能只看图标
按照WCAG 2.2文字对比度说明，普通文本通常需要至少4.5:1，大号文本至少3:1；禁用内容、标识等存在规定的例外。评审时用颜色工具测文字与实际背景，不能只凭显示器上的观感，也不能把灰色小字一律当成次要信息而不管是否读得清。
点击范围要按可触发区域检查，而不是只量图标。在移动端试着连续点击编辑、关闭和删除，观察相邻操作是否容易误触；窄屏还要检查固定操作栏是否挡住字段提示。键盘走查时，确认能依次到达交互元素、焦点可见，打开弹窗后不会继续操作被遮住的底层页面。设计稿中无法确认的键盘行为，写进交付要求，在实现后再验收。
把主观意见改成可复核问题
“看起来不够高级”无法执行，可以改成“主按钮与次要操作的层级是否在窄屏仍明显”“错误提示是否贴近出错字段”“同一组件在列表和详情页的间距是否一致”。每条意见带页面编号、状态、影响和建议动作，避免评审后没人知道改哪里。
把评审意见写成可执行的记录
每条问题先描述观察，再说影响，最后写决议。“颜色不好看”只是偏好；“订单状态与退款提醒同用灰色小字，用户难以辨认是否已退款”则能定位到一个任务风险。没有证据支持时，可以记为需要观察的假设，不必立即把个人意见写成必须修改的结论。
| 原始意见 | 可执行的记录 | 如何确认解决 |
|---|---|---|
| 按钮不明显 | 地址编辑页，保存按钮与取消同等强调；将保存作为主要动作，取消降为次要 | 窄屏下仍能区分保存与取消，长文案不挤压按钮 |
| 错误提示不友好 | 手机号校验失败只在顶部提示；在字段下说明格式问题并保留输入 | 用户定位到错误字段后可以直接修正，不必重新填写地址 |
| 间距统一一下 | 订单详情的地址区和物流区标题间距不一致；沿用同一信息分组规则 | 同类模块使用相同间距，主次分组仍能被识别 |
再为每条记录补充页面编号、优先级、负责人和处理状态。可将任务无法完成、误操作或数据丢失风险列为阻断项；造成明显理解困难但有替代路径的列为重要项；纯装饰细节单独排期。分级依据是影响，不是谁提出的声音更大。
用案例跑完整评审
订单详情页先评审默认态，再点击编辑地址。提交时模拟地址缺失、网络超时和权限不足，记录页面是否给出不同反馈。设计师修正组件和文案后，研发确认数据依赖与实现边界，产品确认规则。最后将未决问题、决定人和截止时间写入评审记录。
从一次地址保存失败走到关闭问题
- 打开未发货订单，找到修改地址入口；记录用户是否能在不听讲解的情况下发现它。
- 进入编辑页，故意漏填手机号并保存；检查错误提示位置、输入保留和继续操作的顺序。
- 补全字段后模拟保存超时；界面不能直接宣称已保存，也不能清空表单，应允许继续确认处理结果。
- 恢复后完成保存，回到订单详情核对地址是否更新；再走一遍已发货订单，确认不会出现不符合规则的编辑入口。
- 把发现的问题逐一指向对应画面，修正后按同样任务复走；有真实实现时再检查键盘、接口反馈和加载表现。
会后记录不要只剩一份“待优化”清单。已解决的问题写明采用了什么方案，未解决的写明卡在哪个规则和由谁决定；本次不做的项说明原因并留给后续排期。这样下一轮不用重新争论已经确认的取舍，也不会把设计师没有收到的口头意见当成交付缺陷。
准备清单时不要把所有视觉规范复制进每次会议，只保留会影响本次任务的项。进入工作区发起一次带状态和任务路径的UI评审，会后按同一版本回写结论。
