UX 审查
目标
找出用户与其预期结果之间的重大障碍，而非仅仅偏离风格偏好的问题。提供基于证据、按优先级排序且可实施的更改。保留现有优势，承认权衡取舍，避免臆测用户研究或交互测试。
审查模式
- 截图 / 静态设计： 仅检查可见内容。将可能的交互风险标记为推测；不得声称已点击控件、检查键盘访问或看到隐藏状态。
- HTML / 源代码： 如果可用，审查渲染后的UI并检查相关的语义、样式和事件处理。仅凭代码检查不能证明浏览器中的行为。
- 运行中的应用： 如果浏览器自动化或计算机操作工具可用，执行代表性任务并捕获特定视口的证据。不要假设工具存在。
- 对比 / 回归： 对前后版本使用相同的任务、视口和证据标准。识别真正的改进和新引入的回归问题。
- 修复请求： 报告后，如果编辑工具可用，进行范围狭窄的修复并重新验证。如果用户仅要求批评，则不更改文件。
工作流程
- 建立上下文。 确定目标用户、任务、屏幕角色（概览/聚焦/制作/执行）、平台、约束以及任何已知的成功指标。如果未知，则陈述任务假设，而非虚构产品研究。
- 收集可检查的证据。 检查提供的图像、模型、应用程序或代码。如果可行且与请求相称，测试主要流程、展开菜单、使用键盘控件，并检查窄/移动和宽视口。参见 browser-review.md。
- 在修饰之前审核用户成果。 检查：任务清晰度；导航和寻路；可扫描性和层次结构；收集和披露模式；操作反馈和恢复；内容清晰度和信任度；响应式行为；可访问性；视觉一致性。使用 review-heuristics.md。不要假设相同的模式对所有任务都是最优的。
- 将证据与推断分开。 为发现结果添加标签：V 在提供的工件中可见，T 在真实UI中亲自测试过，C 在代码中验证但未执行，H 合理的推测，U 未知/需要测量。只报告实际观察到的情况。切勿将模型模拟称为用户研究。
- 按优先级排序。 分配 严重（阻止完成、造成严重伤害或损失）、高（常见/重要任务中的重大摩擦）、中（有意义但不阻塞的成本）、或 低（次要润色）。考虑任务影响、可能的暴露程度、可恢复性以及证据置信度；不要捏造数字确定性。
- 推荐可操作的修复。 对于每个实质性发现，包括：位置、证据、为何重要、具体修改方案和验证步骤。优先选择3-7个高价值发现；只有在确有必要时才包含更多。明确保留好的设计选择，并在存在真正的权衡时提供替代方案。
- 闭环。 如果请求了编辑，进行针对性更改，重新运行受影响的检查，并报告剩余的限制。如果需要研究，提出一个简短的实际用户任务或实验，而不是猜测偏好。参见 reporting-and-evaluation.md。
护栏
- 不要将批评变成未经请求的品牌重塑或重建；除非引起具体问题，否则保持应用的标识和现有功能。
- 不要不加区分地奖励稀疏屏幕。根据扫描、比较和决策需求评估信息密度。
- 不要将视觉偏好评分视为可用性缺陷。将主观偏好单独标记。
- 不要仅根据静态截图声称菜单损坏；区分尴尬的外观与经过测试的裁剪或无法访问的选择。
- 不要在没有位置、后果和建议更改的情况下使用诸如“改善间距”之类的泛泛发现。
- 不要在没有测量的情况下断言某个设计会提高转化率或满意度。
- 不要混淆启发式审查、自动化检查和观察真实用户：它们提供不同类型的证据。
- 当源数据、截图或代码不足时，说明限制并提供下一步的窄范围测试。
默认报告
- 结论： 一段总结，描述对指定任务的适用性；包括有效的地方。
- 按优先级排列的发现： 按严重性和用户影响排序；每个发现遵循
位置 -> 证据标签 -> 后果 -> 修复 -> 验证格式。 - 保留项： 重要的优势，以免意外退化。
- 未知项 / 测试： 将不确定的产品决策与视觉上可证明的问题分开。
- 如果做了更改： 已更改的工件、实际检查以及未验证的状态。
对于简单的截图批评，使用简短形式。不要让正式的模板掩盖有用的答案。
参考文档加载
- review-heuristics.md：条件检查清单和常见失败模式。
- browser-review.md：基于浏览器的任务协议、视口和可访问性冒烟测试、证据规则。
- reporting-and-evaluation.md：严重性、证据标签、具体示例、版本对比。