设计不是做完的，是验完的。
一、上线两小时后的三张截图
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
纪禾的产品上线两小时，收到三张用户截图。
第一张：用户按 Tab 键七次，焦点始终停在输入框里，保存按钮根本到不了。他的按钮是 div 加点击事件，没有键盘可达性。
第二张：一位用户把系统字体调大后，定价卡片的按钮被文字挤出容器，完全看不见。
第三张：深色模式用户看到的次要文字几乎融进背景，因为那套灰色只在浅色背景上验过。
三个问题都不是功能缺陷，也都不会被自动化测试拦下。它们属于同一类：设计没有被验收。
设计验收常被误解为「好不好看」。对一个人的产品来说，它更接近一份检查表：颜色有没有越界、对比度够不够、键盘能不能走完、不同宽度会不会塌。
二、四类检查
验收只需要四类检查，覆盖绝大多数线上设计事故。
| 类别 | 检查什么 | 失败后果 |
|---|---|---|
| 一致性 | 颜色、字号、间距、圆角是否都在 token 内 | 界面显得拼装，改版无法收敛 |
| 可访问性 | 对比度、焦点可见、键盘可达、语义标签 | 部分用户完全无法使用 |
| 响应式 | 320px 到 1440px 之间是否塌陷 | 移动端或大屏用户流失 |
| 内容 | 空状态、错误态、超长文本是否处理 | 真实场景下界面崩坏 |
一致性检查用扫描，不靠肉眼。 用脚本统计样式里不在 token 表中的值，比一页页看快得多，也不会漏。
可访问性检查有硬标准。 正文对比度 4.5:1、大字号 3:1、焦点环可见、所有交互元素可用键盘到达。这些不是建议，是可以判定的。
响应式检查要卡边界值。 320px、375px、768px、1024px、1440px 五个宽度各截一张图。中间宽度出问题的概率远高于标准宽度。
内容检查要用极端数据。 最长的用户名、最长的标题、空列表、五千条记录、一段中文加英文混排。界面在这些输入下不塌，才算过关。
三、二十项检查表
把四类检查拆成可勾选的项，每次发布前跑一遍。
| # | 检查项 | 判定 |
|---|---|---|
| 1 | 主色只用于强调区域 | 通过 / 不通过 |
| 2 | 所有颜色值来自 token | 扫描无孤儿值 |
| 3 | 字号只使用阶梯内的档位 | 无 13px、18px 等例外 |
| 4 | 圆角只使用三档 | 无随手写的半径 |
| 5 | 同一组件在不同页面样式一致 | 截图对比一致 |
| 6 | 正文对比度 ≥ 4.5:1 | 实测数值 |
| 7 | 大字号对比度 ≥ 3:1 | 实测数值 |
| 8 | 图标与边框对比度 ≥ 3:1 | 实测数值 |
| 9 | 焦点环在深色与浅色背景都可见 | 键盘走查 |
| 10 | 所有交互元素可键盘到达 | Tab 走完全流程 |
| 11 | 表单错误与字段关联 | 读屏可读出 |
| 12 | 图片有替代文本 | 装饰图 alt 为空 |
| 13 | 320px 宽度无横向滚动 | 截图检查 |
| 14 | 768px 与 1024px 布局不塌陷 | 截图检查 |
| 15 | 长文本不溢出容器 | 极端数据测试 |
| 16 | 空状态有解释与入口 | 清空数据检查 |
| 17 | 错误态有原因与下一步 | 断网检查 |
| 18 | 加载态有超时与重试 | 弱网检查 |
| 19 | 深色模式下对比度仍达标 | 切换模式复测 |
| 20 | 所有状态截图已存档 | 基线可查 |
二十项不必每次全跑。 改动只涉及某个页面时，跑该页面相关的项；涉及 token 或全局样式时，全跑一遍。
第 1 至 5 项可以脚本化。 颜色与字号扫描、圆角统计、组件截图对比，都能写成一次性脚本，长期复用。
第 6 至 12 项需要人工判断。 对比度可以工具测，键盘走查必须自己按。用键盘完整走一遍注册、保存、删除，是最有效的可访问性检查。
第 13 至 20 项靠截图与极端数据。 准备一份「最坏情况数据」，每次验收都用它，比临时造数据可靠。
四、截图基线与三十分钟走查
验收要能对比，就必须有基线。
截图基线
页面：首页、定价、列表、详情、设置、空状态、错误态
宽度：320 / 375 / 768 / 1024 / 1440
主题：浅色 / 深色
命名：页面-宽度-主题-日期.png
三十分钟走查
0–10 分钟：自动化扫描（颜色、字号、圆角、对比度）
10–20 分钟：键盘走完全流程
20–30 分钟：极端数据与五个宽度截图对比
基线截图要进版本库或固定目录。 只存在本地截图工具里，换一台机器就没了。基线丢失，验收就退化成凭记忆。
对比要看差异，不要重看全图。 用图像对比工具标出变化区域，只有非预期变化才需要处理。
走查要在发布前，不要在发布后。 上线后再发现可访问性问题，修复成本是发布前的三到五倍，因为还要处理已经在使用的用户。
验收记录要留一句结论。 「本次 20 项通过 18 项，未通过：第 9 项深色焦点环、第 15 项长标题溢出，已排期。」比一个「已检查」的勾有用得多。
五、行动清单与复算验收
- 选定五个宽度与两种主题，建立截图基线目录
- 写一个扫描脚本，统计不在 token 内的颜色、字号、圆角
- 用键盘完整走一遍注册、保存、删除流程
- 实测正文、大字号、图标三处对比度并记录数值
- 准备一份最坏情况数据（超长文本、空列表、五千条记录）
- 在每个宽度下检查横向滚动与布局塌陷
- 检查深色模式下的对比度与焦点环
- 把本次验收结论写成一句话，记录未通过项与排期
验收标准：能报出本次通过项数与未通过项编号。 只回答「都看过了」的，说明没有基线也没有记录。
验收通过率 = 通过项数 ÷ 适用项数
发布门槛建议：100%（未通过项必须有排期）
连续三次低于 80%：说明检查表没有进入发布流程
使用边界与实操验收
本文讲通用设计验收，不涉及多语言下的漏译、回退与截图回归，那属于本地化测试：漏译、回退与截图回归 ；用户能否走通任务属于可用性测试：五个人、三个任务、一张表 ；token 的定义属于第 04 篇；物料规格属于第 08 篇。
本文也不主张「二十项每项都要自动化」。一个人的产品，脚本化前三类就足够；可访问性与内容检查必须手动，因为它们的失败方式太具体，脚本很难覆盖。
验证以线上事故为准：连续两个月，统计因设计问题（而非功能缺陷）产生的用户反馈。数字下降，说明验收在起作用；数字不变，说明检查表只是存着，没有进发布流程。
另一个可复算的指标是返工率：验收后到上线前，因设计问题产生的改动数。目标是个位数，超过十项说明验收跑得太晚。
关键参考与核验范围
本文的清单与阈值为教学演示。核验日期：2026-10-24。
- WCAG 2.1 Quick Reference ：可访问性成功标准的完整清单，可作为第 6 至 12 项的对照。
- WebAIM: Contrast Checker ：对比度的公开计算工具，可复核本文的 4.5:1 与 3:1 判定。
上述两条只用于说明公开标准与工具，不构成对任何合规等级的承诺。具体适用等级需按产品面向的地区与行业要求确定。
系列导航
- 上一篇：视觉物料：图标、截图、演示图与素材清单
- 下一篇：品牌延展与退役：第二个产品共用还是另起
- 回到目录：一个人把产品做得像样：品牌、视觉识别与设计系统
- 相关阅读：本地化测试：漏译、回退与截图回归 、可用性测试：五个人、三个任务、一张表
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。