软件UI评审意见总是反复，怎样用真实任务做小范围可用性验证
不要用投票决定所有界面问题。先选一项明确任务，让目标使用者在不被提示点击路径的情况下完成；记录阻塞、误解和恢复，再把证据与视觉偏好分开讨论。
阅读目录5 个章节
先定义这次评审要证明什么
一次评审可以确认“使用者是否找到待办并理解处理后果”，不宜同时验证所有流程、所有角色和所有配色。写下研究问题、目标角色、任务起点和正确完成条件，选择能回答这些问题的原型范围。页面尚未实现的数据或反馈要提前说明，避免把原型限制误认成真实系统性能。
参与者应熟悉相应业务，但不要求已经知道新页面入口。只找设计和开发人员自测，容易漏掉术语和默认知识问题；只找对业务完全陌生的人，也可能把业务培训需求误认为布局缺陷。
任务描述给目标，不泄露按钮名称
GOV.UK主持式可用性测试指导强调观察参与者完成具体任务，并让任务与使用场景相关、避免提示答案。企业项目可以采用这类方法，但不能据小样本结果声称代表全部员工，更不能凭测试次数保证转化率。
假设任务是查出一条被退回申请的原因并补充资料，可以给出申请背景和完成目标，不要说“点击右上角退回记录，再点第二个按钮”。两种写法测到的东西不同：前者观察发现路径，后者只验证照做能力。
记录行为、解释与偏好三个层次
- 行为：在哪一步停住、点击了什么、是否走错记录、是否能自行恢复。
- 解释：使用者认为标签或状态是什么意思，下一步预计会发生什么。
- 偏好：觉得某种颜色更舒服或希望按钮更靠近，先单独记录。
“喜欢蓝色”不能证明任务更好完成；“以为已保存，实际上没有”则直接涉及业务风险。观察者可在任务结束后追问理由，不要在每次犹豫时立即教用户操作，否则无法判断原设计是否足够清楚。
怎样安排有限的样本与资料
先覆盖会影响路径的角色差异，例如发起人与审核人，而不是只凑人数。可从少量代表性任务开始，发现明确问题后修正并复测；如果要比较完成时间或通过率，需另行设计样本和统计方法，不能把几次走查包装成量化调查。
没有安全的测试数据时，应构造明确标注的假设记录，保持业务关系完整。不要把真实账号、个人资料或机密附件放进未经授权的演示环境。录屏与观察笔记应只保留解决设计问题所必需的信息，并按约定管理。
把发现转成可复验的修改
- 写明任务、原型版本、观察行为和造成的后果。
- 区分必须修复的阻塞、需进一步验证的疑问和单纯偏好。
- 修改一个可解释的原因，例如标签、分组或反馈，不同时重做整页导致无法比较。
- 用等价任务再次验证，避免参与者只是记住上一次答案。
- 保存仍未覆盖的角色、终端与异常状态，进入后续验收清单。
业务负责人仍需对流程正确性负责，设计验证也不能替代权限、保存结果和接口的功能测试。小范围测试能降低盲目改稿的风险，但结论应写成“在这些任务和条件下观察到什么”，而不是“所有用户都认可”。
已有产品使用率低时，可先用低使用率诊断排除数据与流程本身的问题；尚未开发的功能则用业务原型组织任务验证。为UI设计评审准备具体任务、角色和观察记录，就能把一次体验讨论转成有证据的修改优先级。