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