带着具体任务查看原型
评审前可以准备三个典型任务，例如销售新建客户、主管审批申请和仓管处理出库。让实际使用者从首页开始完成任务，记录每一步需要的信息和操作。单独展示页面截图容易忽略页面之间的关系，而完整走一遍能够发现入口太深、字段缺失或状态不清楚的问题。评审目标是判断业务能否完成，不是一次性决定所有视觉细节。
每个角色看到的内容应不同
管理员、经办人员与外部用户的操作范围通常不同。评审时应逐个角色检查菜单、列表、详情、附件和操作按钮，尤其关注能否看到他人的记录。对于多人协作的数据，需要说明谁可编辑、谁只能查阅以及谁负责最终确认。角色矩阵最好与原型同时维护，避免开发人员仅凭某张页面猜测权限。
把空数据与异常结果画出来
新账号可能还没有数据，用户可能输入重复编号，也可能上传失败或提交后等待审核。原型需要说明这些情况下页面显示什么、用户下一步可以做什么。如果只设计“所有资料都齐全”的正常画面，开发时就会临时出现大量未经讨论的提示和分支。针对核心表单，至少要覆盖必填错误、保存成功、重复提交和无权限查看。
评审结论要形成可执行记录
把问题分成业务规则待定、页面调整和后续优化三类，并为待定事项指定负责人。每次修改需要说明原问题、调整结果和影响范围。对新增功能，应同步检查范围、工期与验收清单，不能只在会议中口头说一句“顺便加上”。经过确认的版本应有明确标识，开发、测试和客户都使用同一版作为依据。
用一张清单结束评审
评审结束时，核对核心任务是否完整、角色权限是否确认、关键字段是否明确、异常情况是否有处理入口，以及未决定的问题是否有负责人。第一版允许保留少量非核心优化项，但不能让影响业务闭环的问题悬而未决。将确认后的原型与需求清单一起交给开发，能够减少反复猜测，也方便后续按具体任务验收。