网站设计方法与交付检查清单：从内容结构到交互验收

AI 参与说明（Agent：Codex）：本文依据 Practical Typography、Josh W. Comeau、Rauno、Refactoring UI 作者的公开内容及 W3C、GOV.UK 原始文档整理，区分来源观点与本文综合建议。资料核验日期为 2026-10-22；未读取付费书籍或课程正文。任务页案例、参数、取舍及评审流程属于原创综合建议。执行入口 Codex Desktop；本轮模型完整标识与 reasoning effort 未取得任务级运行记录。中文正文按项目 humanizer-zh 编辑。

网站设计需要同时交付内容结构、视觉规则、组件使用方式与完整交互流程。每一项规则都应能解释它服务的任务，并用真实内容、状态和输入方式检查结果。

本文用一个虚构的任务审核产品贯穿 14 项方法：先确定任务与信息结构，再完成 Typography、视觉与布局，最后检查交互、失败恢复和交付规则。具体参数是练习起点，不是通用设计标准；来源观点在对应段落标明。

阅读前先看这些术语

设计工作的范围与阅读顺序

颜色、字号、间距等设计值可以写成 token；网站还需要明确这些值如何组合、适用于哪些内容，以及用户怎样完成任务。下面先列出设计工作及其可检查的产物。

例如“正文最大宽度为 68ch”可以写成 token；但先展示结论还是先展示背景、侧栏放哪些内容、错误后如何继续，都不能靠这个数值决定。类似地，Button 的颜色和半径可以统一，但一个页面是否放了过多主按钮，仍是信息层级与交互选择问题。

下面把这些工作逐项展开。方法来源包括 Practical Typography 的公开章节、Josh W. Comeau 的免费文章、Rauno 的长文，以及 Refactoring UI 作者的公开内容；W3C 与 GOV.UK 用于核对语义和交互边界。来源观点在对应段落标明；任务页案例、参数、取舍和评审流程均为本文综合建议，未使用付费书籍或课程正文。

按需要阅读：第 1 项建立任务与结构；第 2 项补齐排版；第 3–7 项处理视觉与布局；第 8–11 项完成交互、状态和动效；第 12–14 项把方法变成组件规范和交付流程。CSS 机制与完整 HTML/JavaScript 实验可与面向工程师的 UI 设计实践配合阅读。

1. 从任务和内容确定信息架构

先写一句可以观察的任务，例如“审核者找到待处理任务，核对附件和费用，作出处理决定”。然后列出完成它必须知道的信息、可选信息和操作结果。导航名称、页面分区与主按钮都应能追溯到这些需要；不要先画一排空卡片，再寻找内容填进去。下面是本文对虚构任务产品的组织方法。

页面需要回答“现在在哪里、正在处理谁、还能做什么”。导航用于跨主题定位，面包屑解释层级，局部分区帮助理解当前对象；这些入口可以互补，但不必为了完整而全部堆上去。对线性办理流程，给出当前步骤与返回方式可能更有效；对知识库，栏目、目录和搜索往往更重要。

语义结构也参与导航。W3C 的页面结构教程建议用恰当的区域、标题与内容元素表达关系，帮助不同用户跳到需要的位置。视觉上的“顶栏”“侧栏”还需要与实际页面区域对应，不能只剩一堆外观相同的容器。WAI：Page Structure

验收：给未参与设计的人一个具体任务，只记录其点击路径、误入的位置和不知道如何继续的时刻。再只读标题与导航名称，看能否预期内容；从搜索直接进入详情页时，也能识别对象并找到下一步。这样的短评审用于发现问题，不宣称已经完成正式用户研究。

2. Typography：把字体、文字结构与阅读细节写完整

先把正文的字体、字号、行宽与行高调顺

Practical Typography 将正文作为起点，重点检查字体、字号、行距与行长。网页可以先放入三段真实中文，含数字、链接和英文术语，固定字体后再逐项调整；不要只看一个大标题就决定全站文字。Body text、Typography in ten minutes

对任务说明，本文建议先比较不同正文宽度，再调整字号与行高，观察读完一行后能否自然找到下一行。可以用 1rem 字号、1.65 无单位行高和约 36rem 的内容宽度作为中文练习起点；这些是本文参数，不是原书给出的中文标准。西文建议中的字符数也不能直接换成汉字数量；68ch 取决于字体中数字 0 的字宽，不表示恰好 68 个字。CSS Values：ch

段落用语义元素区分，再用间距表达关系；不要连续插入空行或多个 <br> 代替段落。长文可以采用段间距，也可以按具体文体考虑首行缩进，先选清楚的规则，不把两种效果机械叠加。标题更靠近其引导的正文，段间距则与正文行高区分。Space between paragraphs

验收：一项一项改变字体、宽度、字号与行高，完整读几段并检查中英混排；再插入两行标题、长链接和放大后的文字，原来的关系仍然成立。页面需要退让时，先调整布局与宽度，不把缩小整页文字作为默认修复。

字体先分工，再决定是否增加一套

字体选择应从内容开始。正文需要连续阅读，按钮需要快速辨认，代码需要区分符号，宣传标题可能需要品牌个性。先给这些内容命名并固定分工，再比较字体：更换一套字体是否解决了原来的问题？只有“看起来不同”，不足以解释增加下载、授权与维护工作的必要。Butterick 也强调，字体可以混搭，但每套应有稳定角色；同一套字体配合字号和字重已经能形成不少变化。Mixing fonts

任务页可用一套正文/UI 字体，加一套代码字体；若文章正文另用衬线字体，应让所有长文沿用，不要只给某一段临时换字体。选择时把真实的中文、英文大小写、数字、括号和路径一起比较，例如“预计完成 API v3 迁移，附件 build-128.zip”。检查常规、粗体和链接，并观察 0/O、1/l/I 等项目中需要辨认的字符。

发生 Font fallback 时，浏览器会在当前字体缺字时继续查找后续字体，最终回退还可能因设备而异。因此，一个 font-family 声明不表示整段一定由同一字体绘制。中文落到回退字体、英文使用品牌字体，可以是正常设计；要检查两者的大小、粗细与基线是否协调。CSS Fonts：字体匹配

验收：在目标设备看同一份样张，再阻止 Web 字体请求看回退结果；标题仍完整，按钮没有截字，重要数字可辨认。字体许可、文件大小和加载失败也要纳入选择。不能只根据设计工具中的一行英文决定中文网站字体。

标题先说明结构，再用尺寸区分

如果任务页必须用五种字号、颜色和下划线才能说明章节关系，应先检查内容是否分得过细。Butterick 建议减少层级，并提醒不要把固定数学比例当作视觉质量的证明。这是作者的编辑观点，不是 HTML 只能有三级标题的规范。Headings

本文建议先整理“任务说明—提交条件—附件要求”这样的父子关系，再为它们分配标题等级。视觉大标题、卡片标题和正文小节属于不同角色，不能因为某个字号好看就改成同一级。标题用语尽量直接表达主题或结论，“上传前核对附件类型”比“其他事项”更容易预测内容。对连续的说明页，标题以上留白大于以下留白，能让它更靠近所引导的正文；字号和字重只需拉开足够差别。

验收：只读标题即可复述页面结构；最长标题换成两行后，层级仍明确；去掉颜色后，上下级仍可辨认。另检查文档结构中的标题等级，不把视觉效果等同于语义结构。

给强调分配职责，避免一段里互相竞争

粗体适合让关键词在扫读时浮出来；它的作用依赖旁边还有正常字重的文字。Butterick 建议少量使用粗体或斜体，并避免层层叠加强调。书里关于西文斜体的偏好，不应直接改写成中文斜体规范。Bold or italic

在任务说明中，可以强调“提交后不能修改附件”这一限制，其他句子保持常规字重。如果整段都很重要，应改进段落顺序、标题或独立提示区，而不是把整段加粗后再给其中一句加红、加底色。粗体负责重点，代码样式负责可复制的标识，链接样式负责跳转，状态标签负责状态；相同外观最好不要同时承担这些不同职责。

验收：快速扫读时，强调部分确实覆盖需要先知道的信息；逐句阅读时，其他信息没有被挤成难以看清的“灰色背景”。尝试去掉一半强调，若理解没有损失，原来可能用得过多。这是编辑练习，没有固定的粗体比例。

列表表达关系，缩进服务于续行

步骤之间有先后依赖时用有序列表，并列条件用无序列表，术语与解释可以成对呈现。不要为了“更像设计稿”手写圆点、空格和序号。Practical Typography 对 HTML 也直接建议用 <ul> 与 <ol> 生成列表。Bulleted and numbered lists

任务页中的“选择附件—核对预览—提交”是顺序；“支持 PDF”“单个文件有大小限制”是条件。列表项换行后，续行应对齐正文开头，序号留在单独的窄栏。列表内部间距用于区分条目，列表与前后段落的间距用于区分内容块；两种距离不要混成每行都一样大。

验收：插入、删除和调换条目后，序号仍正确；双位数序号及三行长条目不挤压正文；如果嵌套得需要反复数圆点才能认清层级，改成小节或简化内容。

正文链接要让人先认出，再决定是否点击

Butterick 反对把下划线当作普通强调，概要规则也为网页链接留有例外。网站不宜据此直接移除全部链接提示：正文里的可点击文字需要可辨识。WCAG 的 G183 是一种充分技术，说明仅以颜色与亮度区分正文链接时，链接与周围文字的对比应达到 3:1；链接文字自身对背景的可读性仍需单独检查。该技术不是 WCAG 唯一允许的实现。Underlining、Summary of key rules、W3C：G183

本文建议长文默认保留下划线，把颜色用于补充；导航栏、按钮等已有明确形状和位置的链接可按各自模式处理。“查看附件格式要求”也比一串重复的“点击这里”更容易判断去向。不要让普通强调文字套用同样的蓝色下划线。

验收：不用移动鼠标，也能找到正文链接；Tab 移入后焦点清楚，深浅背景下仍可辨认；单独读链接文字，大体能理解目标。长 URL 则检查换行，不能靠缩小整段文字解决。

对齐和换行：让阅读路径稳定

长段居中时，每行起点变化，读者也难以把文字与旁边的项目对齐；Butterick 因此把居中主要留给短语和标题。网页任务说明可以先采用起始端对齐，居中留给少量、确实需要的展示内容。Centered text

两端对齐也需要单独判断。Butterick 对西文网页的主要担忧是词间空隙失控，不能将其推导成所有中文两端对齐都错误。中英混排说明含长术语与链接时，可先用自然换行；想要整齐边线，再检查不同宽度下的真实段落，是否出现显眼的空洞。Justified text

硬换行适合地址等确有结构的内容，也能控制固定标题的断句；但网站宽度、字体和文案都会变化。任务标题若只是为了当前截图好看而插入 <br>，换个宽度可能又多出一行。普通正文优先交给浏览器重排，少量不可分割的短组再局部控制。Hard line breaks

例如把数值和单位写成 24 MB 可避免二者分到两行；它会缩小可断行空间，不能把一整句都用不换行空格粘起来，也不要用多个   模拟缩进。Nonbreaking spaces

验收：更换长标题、调整容器宽度并放大页面，重要短组保持合理关系，整页不横向溢出。排版需要同时接受“保持关系”和“允许退让”这两个约束。

标点、数字和代码分别校对

出版正文中的引号可以按语言规则使用弯引号。本文为技术网站补充一项边界：命令、JSON、属性和可复制代码必须保持原字符。技术网站不能全局把直引号换成弯引号。Butterick 的直弯引号章节提供的是正文排版原则，代码的可执行性在这里构成明确边界。Straight and curly quotes

范围、负数、文件名与连接符也不是同一种语义：“10–20”表示范围，build-128 中的短横线属于标识；编辑时不能为了外观一律替换。中文正文的停顿、引号和省略号另按中文文体统一，不照抄英文破折号规则。Hyphens and dashes

代码字体应放在代码、命令和标识上；费用表只需等宽数字时，不必把整表改成代码字体。原书也区分了等宽正文与代码引用的用途。Monospaced fonts

验收：从网页复制命令、引号和标识，与原输入比较；搜索同一内容能找到预期结果；数字的精度、币种和单位清楚。对“专业排版”的改动，如果破坏复制、搜索或执行，就应撤回。

字距与字体特性最后处理

字距适合针对具体字体、字号和用途微调，不宜给全站正文统一增加。Butterick 针对西文连续大写提出加字距建议，同时提醒不要把字母拉得过散；这不等于中文段落也应该套同样百分比。Letterspacing

连字同样属于细节选择。不要把 fi 等字符在内容中手工替换成特殊连字字符，以免影响搜索和文本处理；选择字体提供的字形功能更合适。作者对装饰连字的好恶是风格判断，网站应按实际阅读需要选择。Ligatures

验收：先在同一段文字上对照开关效果，再检查常规、粗体与斜体。只有标题或小标签需要的微调，应限制在对应角色；正文已经清楚时，保留默认通常比继续增加参数更容易维护。

3. 用视觉层级、间距与密度组织信息

视觉层级：先决定阅读顺序，再选择强调方式

Refactoring UI 作者的免费文章明确指出，文字层级也可以通过字重与对比建立，不必全部依赖字号。作者免费文章

本文练习：给任务页的每个元素标注职责：任务名负责定位，状态说明进度，截止日期提供约束，“保存修改”完成当前操作。先把标题、正文、元数据设为相同字号，只改变字重、位置和留白，做出可辨认的阅读顺序，再决定是否需要放大标题。这能检验页面究竟依赖结构，还是只靠几个大字撑住。

例如，任务名与任务编号不必同样粗；编号可留在附近，保持可读。表单里“保存修改”可以有明显背景，“取消”采用较轻样式；“删除任务”放入独立的危险操作区域。主次由当前任务决定，危险不自动等于醒目。验收：让未看过页面的人指出页面主题、当前状态和下一步；记录他们先看到了什么。灰度截图可辅助排查，但不能代替实际颜色对比检测或用户测试。

间距：把内容关系变成可比较的距离

同样的间距用在所有地方，会让标签不知道属于上面的值还是下面的输入框。本文建议先圈出内容组，分别定义组内、组间与页面分区的距离，再提炼少量间距档位。留白也能承担区分作用；不必每次增加容器边框。Refactoring UI 官网公开示例

在练习中，可让标签到输入框为 8px，两项字段之间为 20px，表单分区之间为 36px；数值只用于制造清楚的距离差，随后根据字体与内容调整。表单标题的下间距应让它更靠近所属字段；错误信息贴近出错项，避免落在两项正中。验收：临时隐藏背景与分隔线，只看位置仍能判断归属；插入一条两行错误说明后，原来的分组关系没有消失。

密度：保留任务所需的信息，减少无意义的容器

密度高低需要随任务选择。这是本文的工程建议：查看十条费用是否异常，与阅读一段任务说明，所需的空间分配不同。先写出要完成的动作，再决定列表每行显示什么、哪里需要展开；不要单纯把整页字号调小。

费用审核页可以紧凑排列项目、金额与异常标记，把长备注展开查看；任务说明页则保留完整正文和较宽松的行距。先删掉重复标签、装饰图标和一层层卡片，再缩减行距。验收：用同一组虚构数据分别完成“比较金额”“找出失败项”“读懂原因”，检查信息能否连续比较，重要内容是否被折叠或截断；不能只根据首屏能装下几行评价设计。布局实现可参考 Josh 对 Grid 的二维轨道与内容约束的讲解，密度取舍由本例自行提出。CSS Grid

4. 为内容选择宽度、布局与响应式策略

内容宽度：为正文、表格和图片分别安排空间

Josh 的 full-bleed 文章展示了一个有用结构：正文限制阅读宽度，部分媒体可以占用更宽的区域。它说明不同内容不必受同一个宽度约束。Full-Bleed Layout

本文把任务页拆为三种宽度角色：说明文字保持适合逐行阅读的宽度；费用表允许更宽以容纳比较列；附件截图可以展开查看细节。宽屏上剩余的空间可以留白，无需拉长输入框填满。验收：增加一段长说明和一张宽截图，正文没有因此变成很长的行；表格也没有为了服从正文宽度而把金额挤成多行。窄容器下分别选择换行、重新组织或局部滚动，不把整个页面变成横向滚动区。

响应式：根据内容失效的位置改变结构

Grid 能同时安排行列；容器查询则允许组件根据自己得到的空间变化，而不只看整个视口。两者解决不同约束。CSS Grid、Container Queries

本文练习：先放入最长任务名、两行状态和三个真实长度的操作按钮，逐渐缩窄容器；记录哪一个关系先失效，再决定何时把工具栏移到下一行。任务卡片同时放在宽主栏和窄侧栏；如果结构选择依赖的是卡片宽度，就按其可用空间处理。不要因为某个常见设备宽度就机械增加一条规则。验收：在临界宽度两侧来回调整，信息顺序稳定、按钮完整、没有突然遮挡；DOM 顺序也要能解释键盘的前进路径，视觉重排不能只顾截图。

5. 设计颜色角色、反馈状态与深浅模式

颜色：先写用途，再挑颜色，再检查状态

本文建议先列页面中需要颜色表达的职责：正文、辅助说明、链接、选中、成功、警告、失败、焦点；品牌色是其中一个用途。之后检查每个用途在默认、悬停、聚焦和选中状态下的实际前景与背景。Josh 的颜色文章解释颜色格式及其调整方式，但选择某一种格式并不自动保证可读。Color Formats

例如，状态不要只显示绿点与红点，应显示“已完成”“处理失败”；正文中的链接保留可识别的可见样式；辅助信息不能通过极低透明度消失。验收：去掉色相后仍有文字、形状或位置线索可判断意义；再测实际颜色组合。WCAG 1.4.3 通常要求正文文字对比至少 4.5:1，符合条款定义的大字至少 3:1，并有明确例外；1.4.11 适用范围内用于识别控件、状态和图形的必要视觉信息要求至少 3:1，不是要求页面每条装饰边线都达标。Contrast Minimum、Use of Color、Non-text Contrast

深浅模式：逐个验证角色关系

以下是本文根据颜色与表面机制提出的工作方法：浅色截图通过后，分别列出页面底层、卡片、浮层、分隔、正文、弱化文字、状态提示和焦点，再为深色模式核对相邻关系。不要只把黑白互换，或者把浅色模式的阴影原样复制。

练习时在同一页并排放一个普通卡片、一个展开菜单和一条错误提示；切换模式后先检查层次与文字，再处理阴影。图表、图片中的文字和半透明表面也要放入真实背景观察。验收：两种模式里都能区分页面、可操作控件和浮层，状态含义一致，并分别测量前景与背景。这里的模式检查表是本文建议，不是 Josh 阴影文章承诺的通用暗色配方。Designing Shadows

6. 分清边界、深度、焦点与层叠

边界与深度：先选择分隔职责，再增加装饰

可以用一次“去掉再加回”的练习检查边界。先临时移除卡片内部的所有线，再逐条问：它帮助比较行、说明容器范围，还是只是在复制 DOM 的嵌套？表面层次则按真实关系决定：普通内容、临时菜单、阻断式弹窗分别需要多少突出程度。Josh 将一致光源与整体协调作为阴影设计的起点。Designing Shadows

例如，任务详情的三个信息组可以只用标题和间距区分；费用表保留便于跟踪行的分隔；菜单有独立表面与适度阴影。验收：关闭阴影后仍能找到必要边界；恢复阴影后浮层更清楚，普通内容没有全部漂浮。需要识别输入框的边界，应另外检查其对比度；“少边框”不能成为删除必要操作线索的理由。

边界、深度、焦点、层叠和裁切应分别检查。边框可以说明容器范围，阴影可以表达浮起，Focus indicator 说明操作位置；它们都不能让元素自动越过祖先的 Stacking context。被 overflow 裁掉又是另一条路径，即使层级足够高，也不代表可以越过裁切区域。原生顶层与组件库的浮层入口有各自机制，使用时应核对实际实现，避免只累加 z-index。Josh：Stacking Contexts

验收：同时打开页头、滚动区域、菜单与对话框，先判断问题是覆盖还是裁切，再检查焦点、关闭和滚动。视觉上盖住了内容，只能证明一个显示结果，不能代替完整的浮层交互验收。关于具体 CSS 推导与可运行例子，见工程实践指南。

7. 让图片、图标与视觉对齐服务内容

图片：先决定阅读目的，再决定裁切方式

CSS 的 cover 会保持比例填满盒子并可能裁切，contain 会保持整个对象可见并可能留白；改变显示位置可以调整裁切关注点。这是布局行为，不是自动理解图片主体。CSS Images：Object Sizing

本文练习：任务附件里，摄影封面可以按固定比例裁切；费用截图需要看清表头、金额与注释，适合完整展示或提供原图查看。不要统一套用一种策略。上传横图、竖图、人物偏在一侧的图、白底图和透明图，分别观察。验收：人物脸部和截图关键信息没有被意外裁掉；内容类图片有说明与合适的替代文本；封面文字如覆盖在照片上，要使用可预测的底色或遮罩，并按不同照片实际检查对比度。

图标与视觉对齐：结构稳定后再做微调

作者免费文章提醒，矢量图放大不会像位图一样失真，但小尺寸图标的形状不一定适合做大图；Josh 则用例子说明，数学居中与视觉居中可能不同。Refactoring UI 免费文章、Pixel-Perfect Dream

本文练习：选定一套图标后，比较线条粗细、实心与线框风格及其在按钮里的视觉重量。大面积空状态需要插图时，先选适合该尺寸的素材，或让小图标保持原有尺度、放在较大背景形状中。对标题边缘、播放三角和圆形徽标做微调前，先确认字体已加载、布局对齐正确；只对稳定资产做局部校正，别给动态数字逐字设偏移。验收：正常缩放下看起来协调；换成两行按钮文字或不同数字仍正常；微调没有改变点击范围、裁切焦点轮廓或掩盖真正的布局错误。

8. 完成命中范围、焦点路径与输入替代

让用户先看懂哪里能操作，再改善点击手感

按下之前，应先让用户知道哪里可以点、点了会发生什么。任务标题如果只是文本，不要套上与链接完全相同的下划线和颜色；附件名如果打开预览，应使用链接或明确的预览按钮。列表里的状态标签若只能读，就不要加上与按钮相同的悬停和按压效果。这是本文对“视觉线索与实际行为一致”的建议。

图标的可见尺寸与实际命中范围可以不同。三点菜单图标可以保持小巧，由按钮的内边距提供更大的操作范围；不要只扩大看不见的伪元素，让相邻按钮的命中范围互相覆盖。行内有复选框、附件链接和菜单时，先画出各自边界，避免“整行可点”吞掉内部操作。

WCAG 2.2 的 2.5.8（AA）规定指针目标至少为 24 × 24 CSS 像素，或满足间距等列明的例外。它是最低要求，不代表达到这个尺寸就一定舒适；正文中的行内链接也有例外，不能给每个词硬套按钮高度。Target Size (Minimum)

操作与验收：临时给所有交互元素画上轮廓，在图标四周空白与相邻按钮之间点击。确认点得到预期按钮、不会串到删除动作；再遮住指针提示，仅凭文字和外观判断操作入口。不要把“鼠标移上去才知道可点”当作唯一发现方式。

按下可以预览，真正执行需要明确提交点

按下删除按钮时改变背景，是输入反馈；立刻发送删除请求，是业务提交。两者不应绑在一起。普通按钮优先采用平台提供的激活行为，使用户按下后移出目标再松开时有机会取消，而不是为了“更快”统一在 pointerdown 提交。WCAG 2.5.2（A）列出释放触发、取消或撤销、释放反转等路径，以及确有必要的例外。Pointer Cancellation

验收：按下目标、保持按住、移到外面、再松开。预期取消的动作没有提交；长按预览关闭后回到原状态。拖动场景另测返回起点与指针取消，不要把普通按钮的取消行为直接套成全部手势规范。

把焦点路径当作页面流程来设计

有一圈焦点轮廓，只解决了“现在在哪里”；还要回答“下一步到哪里、关闭后回哪里”。APG 将组件间导航与组件内部导航分开：通常以 Tab 在组件之间移动，以方向键在菜单、标签组等复合控件内部移动。给一个自制控件加上 ARIA 角色，并不会自动获得这些键盘行为。Developing a Keyboard Interface

给任务详情页写一张焦点流程表，通常比凭感觉逐个补 tabindex 更有效：

表中模态对话框的进入、圈定、Escape 与恢复依据 APG；模态期间，背景对键盘与指针都应不可操作。删除和新增的具体落点是本文结合任务列表做的选择。内容很长时，初始焦点可能更适合放在标题等静态元素，不能一概自动聚焦第一个输入框。Dialog (Modal) Pattern

焦点状态也要与选中状态区分。列表中原先选中了任务 A，键盘移动到任务 B 时，不能仅凭同一个背景色判断两者。固定页头、底栏和 Cookie 提示还可能遮住焦点项；WCAG 2.4.11（AA）的最低要求是控件获得焦点时，不能完全被作者创建的内容隐藏。本文建议进一步尽量完整露出控件与轮廓。Focus Not Obscured (Minimum)

验收：拔掉鼠标，从页面进入到打开、编辑、取消、重新打开、保存，再删除记录，全程能说出当前焦点位置。加上固定底栏后重测最后几个按钮，确认滚入视口并没有滚到遮挡层下面。

让提示与替代入口覆盖不同输入方式

悬停提示可以补充“这个图标是什么”，不适合承担唯一操作说明。需要填写的文件格式、删除后果与必填条件应在需要它们的位置持续可见。提示中若有链接或按钮，就要按可交互浮层处理，不能只画一个看起来像 Tooltip 的框。

自定义悬停或焦点提示要检查关闭、移入和停留：按 WCAG 1.4.13（AA），在适用范围内应能不移动焦点或指针就关闭；允许指针移入额外内容；保持显示直到触发条件消失、用户关闭或内容失效。条款包含例外，不能把所有浏览器原生提示也算作网站实现。Content on Hover or Focus

拖动排序还需要两种检查：键盘能否完成，以及用户能否用不含拖动的单指针操作完成；后者可以包含多次点击或点按。只补方向键并不足以满足 WCAG 2.5.7（AA）的单指针替代要求。任务行可以增加“上移”“下移”或“移动到……”菜单；滑杆可补精确数值输入。Dragging Movements

验收：不使用悬停完成全部主要任务；指针从触发器移入提示时内容不闪退；仅用点击重新排序一条任务，再仅用键盘完成同一操作。快捷键与手势保留为加速方式，基础入口仍能被发现。

9. 设计表单纠错、异步结果与恢复

先减少不必要的错误，再决定何时验证

不要把输入框染红当作验证设计。先问是否真的需要这个字段、标签能否说明所需信息、可接受格式是否清楚。姓名不应无依据地只允许英文；可无歧义处理的首尾空白，也不应让用户反复修改。

GOV.UK 的验证模式针对其服务表单，建议等用户继续或提交时再验证，避免在用户尚未输完时报告错误；特殊情况应有用户研究依据。这是可参考的产品约定，不是所有网站必须关闭原生 HTML 验证或不得即时提示的通用标准。Recover from validation errors

本文建议在任务页区分三件事：字段下的常驻说明提前交代规则；输入过程中的字数计数提供中性反馈；提交时的错误说明指出已违反的要求。密码强度、查重等过程反馈要允许用户继续输入，不要每敲一个字就抢焦点或跳动布局。

错误必须有位置、原因与改法

“输入不合法”只表达了失败；“任务名称不能超过 80 个字符”才给出改法。GOV.UK 将顶部错误摘要与字段附近的错误配合，摘要链接到相应输入，且文案一致；其错误组件还要求保留已填内容。Error summary、Error message

本文的任务表单可以这样组织：提交后在顶部显示“有 2 项需要修改”；每项链接到字段；字段保留原值、补充具体错误，并通过语义关联让辅助技术取得说明。采用 GOV.UK 的提交后摘要模式时，将焦点移到摘要，再由链接进入字段，帮助键盘用户发现问题。保留焦点的异步状态则通过适当的可访问状态消息报告。网络中断放在提交区域说明“尚未确认保存结果”，不要把所有输入标成错误，因为用户改字段并不能修复网络。

验收：一次制造两个错误，按摘要逐项跳转并修复；确认有效和无效输入都保留。随后模拟服务失败，错误位置、重试方式和保留内容均与字段校验不同。

区分请求未完成、结果未知与明确失败

前文已区分输入反馈与业务提交；进一步实现时，还要写清异步结果的边界。下表是本文工程建议：

确认页、页面内反馈与短暂通知应按后续任务选择。保存成功通常不必抢走输入焦点；需要用户下一步处理的失败，也不能只在角落闪现后消失。WCAG 4.1.3（AA）要求适用的状态消息可由角色或属性以编程方式确定，从而供辅助技术在不取得焦点的情况下呈现；它没有要求把每次内容变化都做成播报。Status Messages

“撤销”必须对应真实能力：恢复到哪里、允许多久、请求是否已经提交、关闭通知后还有没有入口，都需要定义。不可逆操作则在执行前说明对象和后果。不要为了套用通知组件，给实际上无法恢复的数据提供装饰性的“撤销”按钮。

10. 空状态、数据和文案也属于界面

把“没有内容”的原因分开。 新账户还没有任务、筛选后没有结果、无权查看和服务出错，分别需要引导创建、清除筛选、解释访问条件和提供恢复入口。如果都显示“暂无数据”，用户无法判断要不要重试。任务列表首次为空，可以说明任务用途并给出“新建任务”；无搜索结果则保留搜索词并允许清除条件。不可访问的内容应按真实权限规则呈现，界面提示不能替代后端鉴权。

加载状态要交代范围。 页面外壳已经可用、只有费用还在读取时，可以只标记费用区；整页骨架或遮罩会让已经可用的操作也显得失效。Skeleton 的形状应大致对应将出现的结构，避免内容出现后突然把标题和按钮推走。慢任务可以说明正在处理什么；没有可靠进度数据时，不显示虚构百分比。这些是本文对状态表达的建议。

为数据列定义语义。 金额、百分比、标识符、估算值和缺失值需要不同规则。保留编号 00128 的前导零；区分 0.00、尚未估算和无法读取；统一币种、单位和小数精度的前提，是它们确实可以互相比较。排序、筛选与分页改变后，应能看懂当前范围和已选对象。GOV.UK 的 Table 以比较和扫读为目标，并使用表头、caption 等结构；不要只把卡片排成网格来模仿表格。GOV.UK：Table

图表先说明问题，再选择颜色。 比较类别、观察时间趋势、查找异常与显示相对基准偏差，需要不同表达。本文建议先写出结论问题和单位，再决定图形；分类颜色应区分类别，顺序变化应表达数量级，围绕基准的两侧变化要交代基准。不要因为组件提供五种颜色，就默认五条线都具有同等可读性。提供标签、形状、线型或可读数据，不能只靠色相传递意义；复杂图表还需要能解释主要信息的文字替代。WAI：Complex Images

文案说明对象、动作和后果。 “保存”保存哪些修改，“取消”是否保留草稿，“重新处理”会不会重复计费，都影响用户决策。时间说明要交代日期范围或时区，数量说明要交代单位；错误说明尽量包含问题与可执行改法。把“操作失败，请稍后再试”改成与事实相符的“附件未上传完成。已保留任务说明，请重新上传附件”，比再增加一个红色图标更能帮助继续工作。这里的例句是虚构产品文案，只有系统确实保留内容时才能这样承诺。

验收：分别制作首次为空、筛选无结果、部分读取失败、结果未知和成功后的页面；让评审者只根据页面解释状态与下一步。替换为长名称、大金额、负数、零和缺失值，再检查排序、对齐与图表标签，没有为了美观改写数据含义。

11. 用动效表达对象和状态关系

高频操作先确保及时输入，拖动期间跟随当前动作

Rauno 的长文讨论了高频动作、可中断性与触摸遮挡等观察。应用到网站时，应根据实际任务重新决定运动是否有帮助，不将系统案例原样当作所有平台的要求。Invisible Details of Interaction Design

本文建议让命令面板出现时即可接收输入，不等装饰动画结束才开放键盘；拖动面板时由当前输入控制位置，释放后再吸附。用户反向拖动或在吸附过程中重新操作时，从当前可见位置接续，旧动画不能覆盖新意图。操作频率越高，越要检查重复动画是否让用户等待，而非统一套用一个“标准时长”。

触摸滑杆要让读数在手指之外可见；精度不足时提供局部放大、步进或数值输入，而不是只把轨道画细。手势接管与页面滚动也需分工，取消以后保留哪个值应有明确约定。减少动画偏好下保留完整的状态与操作线索，不让运动承担唯一说明。

验收：连续打开、输入和执行命令，再拖一半反向、松手后立即重拖、让指针取消一次。记录是否丢输入、跳回旧位置或提交未确认的动作。触摸遮挡需在实际输入方式下检查；本文列出的是产品验收方法，本轮未将这些建议实现为完整应用。

返回时恢复任务上下文

从筛选后的列表进入详情再返回，本文建议同时考虑搜索词、筛选、排序、原条目和位置。只恢复旧像素值，在列表重排或图片加载后可能落到另一个对象上。先恢复条件，待目标具备可定位的布局后再恢复位置；若原任务已删除，给出可解释的落点，避免飞向不存在的对象。用户已主动滚动时，迟到的恢复不应继续抢走控制。

验收：改变筛选、给列表上方增加内容、删除原条目，再检查返回结果。能找到原任务或理解它为何不在结果中，比“页面回到了差不多的高度”更能说明恢复有效。

用运动交代对象关系，而不是每个变化都播放特效

Rauno 对空间一致性与动势的观察提醒我们：运动可以表达对象从哪里来、去哪里，以及旧状态与新状态是否属于同一对象。原文中的系统行为和作者推测应保留其观察性质，不能成为今天所有设备的保证。Invisible Details of Interaction Design

本文建议在任务页使用三条判断：从附件缩略图进入预览，可以保留共同的位置或形状线索；返回时，若原附件已移走或虚拟列表未挂载，应选择合理退场，不要飞向错误记录；取消当前动画时，让新状态从当前可见值接续。边框、图标和图片素材也要参与测试，纯色卡片变形流畅不代表复杂图片不会出现裁切或拉伸。

评审时先把动画录慢，看对象是否跳源、瞬移、错配，再恢复正常速度连续操作。减少动态效果时保留位置、文案和状态线索；不要让动画成为唯一解释。这里检查的是关系是否清楚，不能仅凭曲线平滑就判定设计有效。

12. 为组件补充 Pattern 与使用规则

把组件样式扩展成使用规则

颜色、圆角、阴影与时长 token 可以保持一致，仍不能决定该用哪个组件。给每个高频模式补一张简短的使用说明：用途、何时不用、内容结构、交互方式、状态、焦点去向、失败与恢复。比如“删除确认”应交代任务名称、影响范围、能否恢复和最终按钮文字；换一个红色 token 不会自动得到这些信息。

按钮和错误文案尤其值得进入组件示例。GOV.UK 建议标签说明执行动作，并谨慎使用多个同等强度的主按钮；破坏性后果还应由上下文和文字说明，不能只靠红色。Button

本文建议把“确定”改为可预测结果的“保存修改”“移到回收站”或“永久删除任务”；数字说明写清单位，时间说明写清时区或相对范围，取消说明是否保留修改。辅助名称不要随意重命名可见标签：WCAG 2.5.3（A）要求含可见文字标签的控件，其可访问名称包含相应可见文字，便于语音操作与识别。Label in Name

最终评审产物可以是一张四列记录：任务、输入条件、观察结果、下一步。让同事完成“从列表找到任务→改名称→处理失败→重新提交→返回原条目”，记录迟疑、误触、丢焦点与信息不明的位置。不要只问“好不好看”，也不要把内部短评审称为已完成用户研究。上述流程与补充模式是本文提出的实践方法，尚需在具体产品中实现并验证。

13. 把艺术方向与设计系统变成可交付的规则

字体、圆角和主色会影响气质，但品牌方向还包括图片题材、裁切方式、插画语言、图标重量、文案语气与页面构图。本文建议先选两到三张代表页面，给每个参考标注具体借鉴点：例如“用大幅摄影解释产品场景”“通过细分隔和较紧密的表格表达工具属性”。不要只用“高级”“科技感”作为评审条件，也不要把不同参考的局部效果全部叠在同一页。

可以对同一任务页做两种方向：日常审核工具强调快速比较、稳定位置和克制的表面；面向公众的产品介绍则强调场景图、主张与行动入口。两者可以共享基础颜色和按钮实现，却拥有不同的信息密度和页面模板。用任务判断取舍，比要求所有页面都套一个视觉强度更容易解释。

设计系统还需要维护选择的理由。一个值只有在跨页面反复承担同一职责时，才值得进入稳定 token；只出现一次的海报装饰可以保持局部样式。组件除了外观，还要记录适用场景、内容边界、状态和交互；Pattern 则组织多个组件完成一项任务。GOV.UK 的 Patterns 也围绕具体用户任务与页面类型，说明组件怎样结合上下文使用。GOV.UK：Patterns

验收：换一个人用现有规范实现第二张页面，记录他必须重新猜测的地方。若每次都重新决定提示位置、错误恢复或主次操作，说明缺少使用规则；若只缺一个局部装饰，则不必扩成全站新 token。

14. 从需求走到交付的一次完整工作流

下面是一套本文建议的实施顺序。可以根据风险和项目规模调整，不需要一次建立大型设计系统。

可以直接采用下面这份原创模板。它不要求特定工具或组件库，适合放进项目设计说明，也可交给 Agent 按项实现。

# 页面设计说明：任务审核

## 任务与内容
- 主要任务：找到待审核任务，核对附件和费用后提交决定。
- 必须可见：任务名称、处理范围、当前状态、费用单位、主要动作。
- 次要信息：任务编号、历史记录、完整技术日志的入口。

## 页面与视觉规则
- 正文、数据区和媒体区分别约束宽度。
- 主操作按当前步骤确定；危险操作另说明对象和后果。
- 标签、值、正文、代码与链接各有稳定角色。
- 深浅模式分别检查表面、文字、边框、状态和焦点。

## 状态与交互
- 列出默认、空、加载、字段错误、服务失败、结果未知和成功。
- 提交时保留输入；未确认服务端结果时不宣称已成功。
- 打开与关闭浮层后有明确焦点位置。
- 拖动或手势有可发现的其他操作入口。
- 返回列表保留适当的查询、选择和原任务位置。

## 验收记录
- 输入或条件：长任务名、缺失金额、慢请求、连续操作、键盘。
- 预期结果：写可观察行为，不写“高级”“丝滑”等形容词。
- 实际结果：记录已执行范围、问题与未完成项。

把规则交给 Agent 时，可以要求它先列内容与状态，再实现页面，最后用实际输入验证。若只有一张静态截图，便只能评价对应画面；不要从截图推断焦点、失败恢复和操作连续性已经成立。修改后也应记下真正改变的行为，例如“移出按钮再松开不会提交”“超时后仍保留输入且说明结果未知”，而不是只记录“优化体验”。

关联阅读

• shadcn/ui 与 HeroUI v3 的 Design Tokens 详细对比：比较组件库暴露的主题角色、状态入口、基础尺度和覆盖方式。
• 界面设计资料：官方形态、阅读入口与核心内容：按公开资料的内容与形式选择进一步阅读入口。
• 面向工程师的 UI 设计实践：CSS 机制与完整实验：将布局、层叠、输入与状态规则落实为可运行实验。
• Frontend 主题导航

参考资料

具体章节与条款的来源已放在对应方法旁。以下按用途列出主要入口，本文未使用付费书籍或课程正文。

• Practical Typography：Typography in ten minutes、Summary of key rules：正文、字体、标题、列表及细节排版；中文参数与代码复制边界由本文另作说明。
• Josh W. Comeau：CSS Grid、Designing Shadows、Stacking Contexts：布局、表面及层级机制；任务页的布局与视觉选择属于本文建议。
• Refactoring UI 作者免费文章、官网公开示例：视觉层级、留白与图标使用。
• Rauno：Invisible Details of Interaction Design：输入连续性、对象关系与运动观察；案例不直接构成所有平台的保证。
• WAI：Page Structure、Developing a Keyboard Interface、Dialog (Modal) Pattern：语义结构、键盘与焦点模式；各 WCAG 条款的范围和例外见正文链接。
• GOV.UK：Patterns、Recover from validation errors：任务模式与表单纠错；本文保留其政府服务场景边界。