17 KiB
description
| description |
|---|
| 把 DSH 页面或弹窗作为整体审查，按设计原则说明问题，并验证有依据的修改。 |
Cookbook：审查 UI 设计
English | 中文
概览
本手册用于明确要求的完整审查，以及由改动影响或回归风险决定需要采用的证据步骤。普通开发按 UI 改动流程走轻量路径，不逐节执行本手册。原则与案例参考提供判断依据，不是必做清单。既有测试、GUI PR GIF 和设计／产品审批继续按原有规则执行。
对齐审查先核对图标完整空间（含有意保留的内部留白）、文字列和间距，再检查实际轮廓。热区不等于图标框；不逐个拉齐 glyph 的像素边缘。判断顺序见对齐原则。
按同前景色规则核对关联图标与文字，包括子菜单值与箭头、搜索占位文字与放大镜；检查明暗主题中的实际颜色和透明度，保留语义例外。
目录
1. 确定受审页面或弹窗
确定用户任务和受影响页面或弹窗。涉及多个区域、使用方或设计取舍时记录范围；明确的局部修改不需要单独写计划。用户明确要求完整审查时，列出指定页面／弹窗及相关状态。不能把局部检查表述成整页结论。
在这个范围内应用判断优先级：先检查对齐与空间分组，再审查密度、层级、状态、组件选型、图标光学和几何。每个发现写成可观察的关系，例如内容与隔壁组的距离反而小于与自身标签的距离。遵循用户指定的顺序和授权；完整审查可以发现多个相关问题，常规调整的实施授权不能替代既有设计／产品审查要求。
编辑前阅读客户端 UI Skill和适用架构。宽度与输入方式变更使用响应式 Skill，令牌规则查阅样式参考，圆角几何查阅圆角标准。本流程补充审查和证据步骤，不另建一套视觉令牌。
按视觉影响选择范围
按下表选择检查范围。较大改动可用几句任务笔记追踪受影响的组、使用方与风险条件；多区域审查确有需要时再用覆盖表。局部修改无需场景清单。文件数量和包边界不能决定视觉影响范围。
| 改动 | 最小检查范围 |
|---|---|
| 局部文案、图标、颜色或间距 | 先看所属页面或弹窗的上下文；检查所属组、相邻组及共用轴线或角色的受影响并列元素，包括远处的并列元素 |
| 页面、表单或卡片布局；新页面或弹窗 | 将所属页面或弹窗作为整体审查，包含相关滚动和展开内容 |
| 共享组件 | 排查全部受影响使用方；在实际组合上下文中检查每种不同的布局、内容和状态变体 |
| 全局字体、令牌或样式 | 梳理受影响的组件族与页面布局，按这些类别扩大覆盖，不能当成局部改动 |
| 没有预期样式变化的行为改动 | 检查可能改变可见关系的状态，包括加载、错误、禁用、展开和焦点 |
只有相关实现、尺寸、容器约束、内容行为和状态等价时，共享组件使用方才能复用证据；记录归类和依据。不确定的场景直接检查。源码排查全部使用方不等于逐页打开过。问题在初始区域外重复出现，或改法影响邻接关系时，扩大范围。无关发现单独记录，不静默开始整个产品重设计。
对每项变化执行最低检查要求：颜色必须查明暗主题；布局、间距、字体和尺寸必须查窄容器与长内容；交互必须查受影响路径和状态。局部修改也要完成这些检查，但不要求每个条件都保存截图。遵守所属响应式与行为要求，不穷举无关组合，也不用固定截图数替代覆盖判断。同一任务中复用未变规则和有效证据，一组相关修改完成后再截图，不逐条 CSS 调整都重拍。只读取相关原则和案例；设计判断不明确时再补充查阅。
2. 检查任务路径与实现
从正常应用入口检查受影响的结果。复用正在运行且使用当前实现的实例，不为每次微调单独重启或重建。沿相关任务路径检查，必要时使用计算样式区分布局缺陷与内容、加载或未结束动画造成的现象。
普通改动说明问题位置、可见现象、修正和验证即可。源码归属、替代方案及改法不适用的条件影响判断时再补充。优先处理可见或共享缺陷；源码数值不同本身不能成为统一数值的理由。
诊断间距时，分别记录布局框、margin、padding、文字行框和字形可见边缘。明确关闭控件按按钮边缘还是图标框对齐，并核对不同图标尺寸下入口与菜单的文本内缩。可见留白的标注不等于测得了 CSS margin。
在整个界面内核对适用规范
按适用规范映射收集本任务相关的当前圆角、材质、字体、组件、反馈、响应式和图案规则，记录明确例外与相关已有变体。个人或外部 skill 不同时，以仓库所有方为准；实现与所有方不同时，把差异保留为发现，不能默默任选一方。
将整页与整个弹窗的审查原则应用于选定范围。保留整体构图上下文，先比较受影响区域与重复关系，再用局部 fixture 分析细节。明确的完整审查覆盖全部区域；局部修正需保留邻接的对齐、分组、嵌套圆角、裁切与焦点关系。
把关系明确写出来
确定相关分组和对齐参照。关系复杂、有争议或需要解释时，才画轴线或标注保留上下文的截图；画图不是阅读 CSS 的前置条件。下表是记录审查时可选的提示，不要求每次局部修改逐项填写。
| 观察项 | 记录内容 | 示例 |
|---|---|---|
| 任务与分组 | 每组描述或操作什么，包含哪些子组，与谁相邻 | 会话标题／三操作组；成员区／任务区 |
| 对齐 | 对象、轴线、参照容器及有意的例外 | 基线定义的同类行文字起点；主按钮内 icon＋文字整体居中 |
| 间距 | 哪些是组内、重复单元之间和组间距离 | 标题与所属卡片比与前一个分区更近 |
| 并列几何 | 可比较角色的可见尺寸、圆角与颜色关系 | 圆形底板等大；搜索提示共用一个前景色角色 |
| 状态 | 同时叠加及相邻共存的组合 | 当前会话选中，同时另一条会话悬停 |
| 证据范围 | 能看到什么，哪些尚未检查 | 完整 Desktop 侧栏与隔离会话行的区别 |
按整体构图、组与组的关系、组内细节三层观察，再用源码与计算几何解释可见结果。对齐比较实际文字起点和槽位中心；间距同时比较可见边界与 CSS 框。区分 CSS 像素与截图像素，保留缩放和设备像素比，不从缩放后的图片推导新的设计常数。
有效发现要说明违反了什么关系：“标题到操作组的距离小于操作组内部距离，视觉上把标题粘到首个操作；分开两组，并重测长标题悬停。”只说“间距不对”或“都使用 token”都没有完成判断。明显不一致即使不阻塞任务，也能构成设计不通过，不能因为仍然点得动就忽略。
宣布页面或弹窗审查完成前，将它实际包含的区域和相关状态与已检查证据逐一核对，包含滚动、展开或切换标签页后才能看到的内容。局部 fixture 或案例不能替代这个整体中尚未检查的部分。局部审查则明确列出未覆盖范围。
用本地维护的生产组件 fixture 复现受控状态或比较变体，作为真实应用检查的补充。截图、报告工具及其场景适配可放在仓库外并读取源码工作树，不作为产品依赖或 CI 验收；支持场景与限制以工具的本地说明为准。
为审查建立覆盖记录
明确要求完整审查，或确有多个区域需要追踪时使用下表。普通局部修改不需要覆盖表，也不必另写笔记重述所有字段。检查受影响的关系，对共享使用方分组时保留有依据的等价判断。
| 页面／弹窗与入口 | 语义组及跨组关系 | 已查条件 | 发现与归属方 | 修正后证据 | 尚未检查 |
|---|---|---|---|---|---|
| 填实际入口与区域 | 指定比较两端、完整框或文字轴 | 内容、宽度、主题、状态 | 记录规则和责任组件 | 对照图与相关行为结果 | 写明限制，不留含糊的“已覆盖” |
复杂问题再说明比较对象、预期关系、支持证据和可能受损的邻接关系。错误修法或复查条件有助于判断时再写；普通发现采用前面的简短形式。证据不足的候选保留为待核实，在选定范围内排查已确认的重复问题，不顺带开展无关清理。
3. 保留起点
明确要求对照，或较大改动及回归风险需要对照时，保留可恢复的起始版本与相关截图。普通局部修改不要求额外源码快照或修改前截图。保留基线时需包含已有未提交改动，不能假定 HEAD 就是当前可见应用，并记录源码身份与截图条件。
需要截图时，把图像及其条件保存在工作树根目录的 .ui-review/，或另行明确选择的本地目录。仓库忽略 .ui-review/ 中的生成证据；审查工具仍可安装在工作树之外。
完整审查或需要追踪多个状态的对照使用场景映射；简单改动可直接检查受影响位置。展开行、弹窗及相关加载／禁用状态影响结论时应纳入，折叠父组件不能覆盖隐藏控件。破坏性或暂不可达状态使用安全 fixture 数据，不为截图而修改用户的真实任务。
4. 修改最小责任组件
修改负责该任务的归属方：页面布局由页面负责，共享控件状态由基础组件负责，跨使用方重复的 glyph 失衡由图标库负责。复用组件与主题别名，验证受影响关系并保留工作区已有独立改动。开发修正无需先写成一条正式审查发现。
检查可能与本次修改冲突的状态，例如选中与悬停或键盘焦点叠加、展开与焦点叠加、忙碌与禁用叠加，以及校验信息与长内容共存。检查窄容器和变更断点两侧的临界宽度。布局变化时保留输入草稿、键盘焦点、关闭方式及主操作的可达性。按测试策略验证行为，不添加只复述 CSS 声明的断言。
先验证造成问题的结构，再确认样式实际生效，最后检查视觉与行为。可记录完整 icon 框、文字起点、按钮可见边缘和热区各自的计算位置；不要拿热区矩形代替全部对齐证据。公共组件的调整至少覆盖有／无可选说明、长短内容与实际相邻控件，不能仅修复报告中的一个 fixture。
构建或热更新状态不确定时，重新建立使用目标源码的独立应用实例并核对产物，避免旧脚本配上新样式。仅因 DOM 快照没变、测试选择器过期或截图钩子失败，不能判定视觉修正通过或失败；定位失败归属，再以更新后的真实行为预期和无截图钩子的相关用例验证。
5. 验证行为与可比较的截图
在实际页面中检查受影响结果及直接相关的邻接元素。必要场景不可用时，说明缺了哪项检查、原因和下一步验证方法；标明来源的生产组件 fixture 可提供部分证据，不能算作实际页面通过。用户要求对照，或解释较大改动、评估回归风险需要时，才额外保存截图和对照；常规修改无需独立报告。这里简化的是留档，不是最低检查或既有 GIF 要求。制作对照时保持内容、主题、语言、视口、缩放、设备像素比、交互状态和内容锚点一致，并等待字体、数据和过渡稳定。
制作对照时，将最终截图单独保存，并按对应的起始场景和相同条件配对。
保留对照时检查尺寸和截图条件；有场景清单时再核对场景 ID。修正不匹配的条件，不拉伸图片、默默改变裁剪，或把重建 fixture 当作更早的应用截图。检查交付图片，确认它们支持所声明的范围。
两次截图的渲染源码指纹相同时，只能演示截图与报告流程，不能证明 UI 改进。真正的前后对照应当在编辑前拍摄起始实现，编辑后拍摄结果实现。交付报告中也要清楚保留这一区别。
整页截图掩盖细小差异时，可使用尺寸相同、内容起点相同的成对裁剪图，并保留足以判断关系的上下文。内容变化确实需要不同裁剪时，说明差异，并保留完整上下文的原图。涉及颜色、状态或图标平衡时验证明暗两种主题；放大图只能补充实际显示尺寸下的检查。
6. 交付完整证据
普通交付说明改了什么、检查结果和重要缺口，简短解释或截图即可。明确要求详细案例报告时，将场景／问题、设计判断与图片放在一起，图注说明来源及关注位置。避免脱离正文的截图集合或无法展示所述关系的图片。
交付需要前后对照时，标明两侧含义并区分真实应用截图与隔离组件场景。用户要求全部修改时，将该范围与最终 diff 核对，包含嵌套控件，并说明缺少的证据。普通修正不要求每项制作成对报告。
完整审查区分已查无发现、有缺陷和尚未检查的区域。普通修改报告结果和重要缺口，无需逐区域状态账目。规则归属、错误修法、例外或复查条件有助于解释发现时再补充。无关检查通过不能抵消已知缺陷。
报告实际运行的检查及结果，区分自动元数据校验、行为测试与人工读图。说明重要限制，例如应用状态暂不可达或某个平台尚未测试。必需场景或检查未完成时，不要声称已经完整验证。
交付、评审和推送时按 UI 改动流程检查新增累计影响或失效证据，不重复已经完成的检查。结果未变时无需额外报告。测试和 agent 检查不能替代既有设计／产品审批要求。
对比交付与累计改动
正式对照报告采用左前右后。有助于解释时才在修改后图片上添加不遮挡内容的标注，并保留原图；交互报告可使用可关闭的叠加层。窄屏选择可读的呈现方式，不强制制作专门的报告界面。普通交付可用简单标明含义的图片或简短文字；既有 GIF 要求保持不变。
累计汇总按位置去重：在条件可比的前提下，将最早可靠的修改前截图与最终实现配对。中间轮次只保留为历史证据，不作为独立最终成果；撤销方案不计入现存成果。另一会话的保留改动单列，不归为本次成果。缺少起点或归属不确定时明确说明。记录实际检查，不将重复执行数量当作新增覆盖。
汇总全部修改时，将每项结论追溯到累计 diff、当前实现所有方及保留证据。区分净改动与基线已有行为，先消解用户后续修订，再给出最终数值。旧截图不再代表当前结果时标为历史证据，并区分源码核验与重新打开场景检查。将可复用的判断回写规则所有方及正反案例，不把局部像素值或缺乏依据的全产品通过结论变成规范。
延伸阅读
按本次审查需要查阅对应归属文档。
- UI 设计原则与审查案例——整页与整个弹窗的判断原则、适用规则及解释性案例。
- 规则归属与维护——原则的修改位置及本地工具的读取方式。
- Web UI 样式参考——组件复用与样式归属。
开发备注
无。