web-design-guidelines

Web 设计指南

当问题是**“这个界面整体表现如何？哪些地方造成了阻碍？我们应该优先修复什么？”**时，请使用此技能。

这是此仓库中广泛界面审查／设计评审的核心参考。 它不只是一个获取供应商规则的工具，也不能替代相邻的专门技能。

在处理广泛的页面或流程评审前，请阅读 references/review-modes-and-categories.md。 在判断工作应归属此处、web-accessibility、responsive-design、ui-component-patterns、design-system 还是 react-best-practices 时，请阅读 references/handoff-boundaries.md。 编写最终评审报告前，请阅读 references/ui-audit-packet-template.md。

适用场景

• 对落地页、仪表盘、注册流程、设置页面或营销网站进行广泛的界面质量评审
• 将“帮我评审一下 UI”或“审查一下这个 UX”转化为结构化审查，而不是零散的意见
• 综合评估层级、清晰度、间距、一致性、组件状态质量、CTA 强调程度和任务阻碍
• 检查某个屏幕或流程是否已准备好进入实现、发布或利益相关者评审阶段
• 根据广泛的界面启发式原则和实用的实现指南评估页面
• 将不同类型的发现整理成一份明确标注交接事项、按优先级排序的 UI 审查报告

不适用场景

• 主要任务是无障碍整改、键盘／焦点行为、标签、语义化 HTML，或手动与自动化 WCAG 验证 → 使用 web-accessibility
• 主要任务是视口适配、溢出、断点策略或容器适配布局行为 → 使用 responsive-design
• 主要任务是可复用原语／插槽／变体 API 设计，或受控与非受控组件架构 → 使用 ui-component-patterns
• 主要任务是系统级令牌治理、视觉语言或组件库基础 → 使用 design-system
• 主要任务是 React 渲染、水合、状态抖动、打包／运行时行为或性能调试 → 使用 react-best-practices 或 performance-optimization
• 任务仅仅是粘贴自动化工具的输出，且不涉及设计判断；请直接运行工具，然后回到这里进行解读并确定优先级

核心理念

广泛的 UI 评审要做好，最好做到：

1. 界定评审范围，
2. 将发现归类到稳定的类别中，
3. 将广泛的界面问题与专业整改事项分开，
4. 根据用户阻碍和发布风险确定优先级，
5. 最终留下简洁的审查报告。

不要假装某一份清单、代码检查工具或供应商指南就能涵盖所有问题。 将规则来源和启发式原则作为输入，再做出判断。

说明

步骤 1：界定评审范围

评估 UI 前，先明确正在评审哪种界面。

可选择一个或多个类别：

• 营销／落地页 — 内容叙述层级、CTA 强调程度、易于浏览性、证明材料、视觉可信度
• 应用屏幕／仪表盘 — 信息密度、任务流程、状态、导航清晰度、可恢复性
• 表单／入门引导／结账流程 — 字段清晰度、顺序、错误预防、进度反馈、确认
• 设置／管理／CRUD 界面 — 标签、破坏性操作的清晰度、默认值、成功／错误反馈、表格／筛选器的复杂度
• 组件集群 — 重复控件的一致性和状态行为，但不涉及完整的组件 API 设计

快速界定：

Review surface:
- Type: application screen + multi-step form
- Primary job: create a new workspace
- Main user risk: hidden next step, weak error recovery, inconsistent button hierarchy

如果请求涉及的页面过多，请先选择一个有代表性的流程或优先级最高的屏幕。

步骤 2：选择评审模式

选择一种主要模式，以限定评审范围。

模式：

• 发布就绪度审计——发布前的全面评审，包含严重程度和修复顺序
• 润色 / 一致性审计——间距、层级、文案强调、组件 / 状态一致性
• 流程阻碍审计——任务完成障碍、步骤含糊、错误处理、流程死路
• 启发式审计——依据可见性、清晰度、控制、一致性和恢复等广泛交互启发原则进行评估
• 规则叠加审计——在更广泛的审计基础上，应用 Vercel Web Interface Guidelines 等外部检查清单或来源

推荐默认选项：

Primary mode: launch-readiness audit
Secondary lens: rule-overlay using Vercel Web Interface Guidelines

步骤 3：按稳定的类别进行评审

不要随意罗列观点。应按类别归纳发现。

使用以下类别：

• 层级和易读性——视觉优先级、章节顺序、留白、分组、标题 / CTA 强调
• 清晰度和语言——标签、CTA 措辞、辅助文本、错误文本、术语、下一步说明是否清晰
• 一致性和组件行为——重复模式、按钮样式、图标使用、字段样式、悬停 / 焦点 / 禁用 / 加载状态
• 交互反馈和恢复——成功 / 错误 / 加载状态、空状态、确认、撤销 / 取消、进度可见性
• 导航和方向指引——方位感、章节标签、面包屑 / 标签页、当前位置感知、退出路径
• 响应式基础——移动端可读性、触控目标是否合理、溢出、堆叠、密度变化
• 无障碍基础——对比度是否合理、焦点是否可见、语义结构、键盘可达性、含义不应仅由颜色传达
• 性能和信任信号——加载缓慢的主视觉 / 媒体、卡顿的交互、布局偏移、体积过大的资源、加载行为不一致

如果某个类别没有实质性问题，请简要说明，不要硬凑发现。

步骤 4：判断问题应留在此处还是转交

此技能负责全面的界面审计，而非每一种专项修复。

常见转交方向：

• 仅涉及无障碍或以无障碍整改为主 → web-accessibility
• 视口 / 容器适配和布局溢出 → responsive-design
• 可复用组件或基础组件 API 重新设计 → ui-component-patterns
• 令牌系统 / 整个库的设计治理 → design-system
• React 代码中的渲染 / 运行时 / 性能调试 → react-best-practices 或 performance-optimization

遵循以下规则：

• 在此处保留诊断和优先级排序，
• 当某个领域明显占主导时，将专项整改计划转交出去。

示例：

Finding: icon-only buttons are inconsistent and two lack accessible names.
- Keep here: note inconsistency and review impact
- Route out: accessibility remediation details to `web-accessibility`

步骤 5：将外部规则来源用作叠加项，而非完整方法

可以使用外部规则来源，但只能将其作为叠加项。

有用的叠加项：

• Vercel Web Interface Guidelines——针对无障碍、焦点、表单、动效、性能和响应行为的实用 Web 实现检查项
• 可用性启发原则——可见性、符合用户语言、控制、一致性、错误预防、恢复
• 工具输出——Lighthouse、axe、设计 lint、视觉回归说明，以及（如有提供）分析 / 热图数据

不要说“已经获取规则文件，所以审计完成”。 应改为：

Overlay evidence:
- Vercel guideline overlap: focus visibility, form semantics, state clarity
- Heuristic overlap: consistency, error prevention, user control
- Tool overlap: contrast and performance warnings

步骤 6：按摩擦程度排序，而非按类别数量排序

根据对用户的影响确定严重程度。

建议的级别：

• 严重——阻碍任务完成、很可能导致用户放弃，或严重损害信任
• 高——在核心流程中造成困惑、反复出错或缺少反馈
• 中——降低清晰度、一致性或效率，但不会完全阻断流程
• 低——润色问题、小的不一致，或适合集中处理的清理事项

如有帮助，也请标注修复成本：

• 低成本 / 高回报
• 中等成本 / 高回报
• 大规模重新设计 / 后续结构性工作

步骤 7：生成简短的审查报告

输出应能帮助他人采取行动，而不只是展示你的观点。

首选格式：

# UI Audit Packet

## Surface
- Screen/flow:
- Review mode:
- Primary user job:

## Top findings
1. [Severity] ...
2. [Severity] ...
3. [Severity] ...

## Findings by category
### Hierarchy and scanability
- ...

### Clarity and language
- ...

### Consistency and states
- ...

## Recommended next moves
- Quick wins:
- Follow-up redesigns:
- Route-outs:

## Route-outs
- `web-accessibility`: ...
- `responsive-design`: ...

如果用户要求简洁的审查备注，请保留各类别，但精简每条要点。

示例

示例 1：全面的发布就绪度审查

输入：“发布前审查一下这个注册流程。我需要检查层级、CTA、状态、移动端和无障碍基础项。”

理想的回复结构：

• 将界面归类为引导流程／表单流程
• 选择发布就绪度审查作为主要模式
• 将发现的问题分为层级、清晰度、状态、响应式基础项和无障碍基础项
• 优先处理最关键的阻碍
• 只有在键盘／焦点修复需要由专家跟进时，才将其转交给 web-accessibility

示例 2：附带转交事项的润色审查

输入：“审查一下这个仪表板 UI 的一致性。按钮、徽章、加载状态和移动端布局都不太统一。”

理想的回复结构：

• 选择润色／一致性审查
• 在本技能范围内处理组件／状态不一致的问题
• 将反复出现的移动端溢出问题转交给 responsive-design
• 避免将任务扩大为全面的设计系统重写

步骤 8：在最终答复中明确范围边界

全面审查的结尾应加上一句话，避免范围重叠。

示例：

• “本报告涵盖广泛的界面质量；详细的键盘／焦点修复应转交给 web-accessibility。”
• “此处已指出主要的响应式溢出问题，但布局适配方案应归入 responsive-design。”
• “此处标出了组件不一致的问题；可复用基础组件／API 的重新设计应归入 ui-component-patterns。”

输出检查清单

完成前，请确认已包含：

• 审查对象
• 选定的审查模式
• 分类后的发现
• 优先级排序
• 必要时明确列出转交事项
• 一份简洁的审查报告，而非零散的观察

最佳实践

1. 从用户任务或页面目标出发，而非罗列随意的视觉瑕疵。
2. 用类别组织审查结果，便于交接处理。
3. 将无障碍和响应式纳入全面审查，但若它们成为主要工作，则将专项修复转交出去。
4. 选择 5 条有力的发现，而非 25 条薄弱的要点。
5. 将外部规则集作为补充，而非判断的替代品。
6. 区分快速见效的改进和后续结构性重设计。
7. 明确说明发布风险和用户使用障碍。

参考资料

• Vercel Web Interface Guidelines
• NN/G：用户界面设计的 10 项可用性启发式原则
• W3C WAI：Web 无障碍评估工具列表
• Roast My Web：UI 审查清单：模板与报告大纲