Apple Hig

---
name: apple-hig
description: 将 Apple Human Interface Guidelines 的设计思想提炼为 Web 产品的设计取舍与界面 review 判据。当用户明确要求 Apple HIG、Apple 式、native-feeling、现代干净克制，或希望以 HIG 为主要判据设计、评审 Web 产品的导航、工具栏、菜单、弹层、列表、图表、加载、反馈、模态、撤销、拖拽、搜索、新手引导时使用；也适用于 GGN 这类可视化 AI 开发过程界面。普通品牌营销页、纯视觉美化、后端业务规则、Apple 原生应用 API 实现不要使用。
---

# Apple HIG for Web

把 Apple HIG 当作一组**判断人如何理解、行动和恢复错误**的设计思想，而不是一套需要复刻的皮肤。用于 Web 时，HIG 负责指出目标、优先级和风险；HTML、CSS、浏览器语义与 WCAG 负责具体实现。

## 使用方式

先判断任务属于哪一种：

- **设计**：先确认用户的主任务、当前上下文、最重要的下一步和必须长期可见的信息，再决定布局与组件。不要从“放哪些卡片、玻璃效果或动画”开始。
- **Review**：必须检查默认态与边界态，包括加载、空、错误、无权限、成功、禁用、键盘焦点、窄屏、长文本、暗色模式。只评价静态首页不足以通过。
- **组件选型**：先读与任务相关的 reference，不要一次加载全部资料。

按需读取：

- `references/foundations.md`：布局、颜色、字体、动效、无障碍及 Apple 的八项设计原则。
- `references/components.md`：侧边栏、工具栏、Popover、菜单、列表与表格、图表。
- `references/patterns.md`：加载、反馈、模态、撤销与重做、拖放、搜索、新手引导。
- `references/web-mapping.md`：Apple 平台概念到 Web 的等效实现，以及不可照搬的条目。

## 核心判据

Apple 的 clarity、deference、depth 在 Web 上应这样落地：

| 判据 | Web 含义 | 通过信号 | 失败信号 |
|---|---|---|---|
| **Clarity** | 用户无需解码即可知道“我在哪、正在发生什么、下一步做什么、结果是什么” | 信息层级、标签、状态、焦点和反馈一致；主任务与恢复路径可见 | 术语含糊、动作藏匿、状态靠猜、错误只说“失败”、视觉层级互相竞争 |
| **Deference** | 界面服务于内容与任务，不抢走注意力；“克制”不等于空白或弱化可用性 | 内容优先，chrome 安静，强调色稀少且有意义，动效只在需要解释变化时出现 | 每个区域都有边框/阴影/玻璃/渐变；颜色和动画争夺注意力；装饰牺牲可读性 |
| **Depth** | 用语义层级、渐进披露和可追踪的转场表达深度，而不是伪造 3D | 层级与任务边界清楚；一次只处理一个语义层；离开和返回可预测；上下文不丢失 | 模态里再做完整应用、弹层套弹层、为动效而动效、导航与撤销混为一谈 |

当判据冲突时，再按 Apple 的八项原则取舍：Purpose、Agency、Responsibility、Familiarity、Flexibility、Simplicity、Craft、Delight。默认优先级是：**安全与可恢复性 > 可理解性 > 主任务效率 > 一致性与熟悉度 > 视觉个性 > 装饰性愉悦**。

## Review 流程

1. 写一句话定义页面的主任务、主要用户和成功结果。无法说清时，先返回产品目标问题，不要做视觉结论。
2. 沿主路径走一遍：进入、理解、操作、等待、成功后继续、失败后恢复、取消或返回。
3. 逐项执行下面的清单。每一项标记 `PASS / FAIL / N/A / UNVERIFIED`，并要求证据。
4. 用真实内容测试：最长标题、中文与英文混排、空数据、大数字、200% 缩放、窄屏、键盘 Only、屏幕阅读器、浅色/深色/高对比。
5. 报告时按严重度排序，不用“现代、干净、高级”作为结论。

严重度：

- `P0`：核心任务不可完成，或存在数据丢失、严重无障碍阻断、不可逆错误。
- `P1`：主任务明显受阻、歧义或需要猜测；典型用户无法独立完成。
- `P2`：可完成任务但有明显认知负担、重复操作、状态不清或跨设备问题。
- `P3`：不影响任务完成的细节一致性与打磨问题。

每条 finding 使用：

`[P?] 标题 — 位置 — 证据 — 用户影响 — 建议修改 — 对应判据/清单 ID`

没有证据的偏好不要写成缺陷。N/A 也要说明为什么，例如“当前产品没有拖放能力”。

## 可执行 Review 清单

### 目标、结构与层级

- [ ] **A1** 首屏能否在 5 秒内说清当前页面、主任务和下一步？
- [ ] **A2** 视觉顺序是否与阅读顺序、任务重要性一致？最重要的信息和动作是否先被看到？
- [ ] **A3** 相关内容是否通过对齐、间距、容器或分隔线成组，非相关内容是否明确分离？
- [ ] **A4** 是否只展示完成任务所需的信息？高级能力是否渐进披露，而不是默认铺满？
- [ ] **A5** 是否存在一个清晰的导航模型？用户能否知道自己在哪、来自哪里、如何返回？
- [ ] **A6** 核心动作是否常驻或在上下文内可见？是否为了“简洁”把关键动作藏进无语义图标或二级菜单？

### Clarity：可读、可懂、可预期

- [ ] **C1** 标签是否使用用户熟悉的领域词和明确动词？是否避免内部缩写、机器命名和无主语句？
- [ ] **C2** 是否只使用一套清晰的字体与字号层级？正文、辅助文字、标题、数字和代码风格能否稳定区分？
- [ ] **C3** 正文是否能承受 200% 浏览器缩放、长文本与窄容器，不重叠、不截断关键信息？
- [ ] **C4** 颜色是否表达一致语义？同一个强调色是否被滥用于品牌、链接、状态、按钮和装饰？
- [ ] **C5** 状态是否能不依赖颜色理解？色盲、灰度、强制色彩模式下是否仍可区分？
- [ ] **C6** 文本与背景、图标与表面、控件边界与背景是否达到 Web 可访问对比度要求？
- [ ] **C7** 图标是否只承担熟悉的含义？陌生或高风险图标是否有可见标签或可访问名称？
- [ ] **C8** 控件是否明显像控件，内容是否明显像内容？可点击区域是否比文字本身更容易命中？

### Deference：让内容与任务占主导

- [ ] **D1** 页面 chrome 是否保持安静？边框、阴影、背景色、玻璃、渐变是否都有明确用途？
- [ ] **D2** 强调色是否稀缺且可解释？是否只有一个主要动作层级，而不是多个“最重要”按钮？
- [ ] **D3** 动效是否用于解释状态变化、空间关系或反馈？高频操作是否避免重复动画？
- [ ] **D4** 装饰性图片、纹理、3D、粒子或渐变是否服务于任务，而非与数据和文字竞争？
- [ ] **D5** 视觉密度是否适合任务？信息密集产品应优先可扫描性，而不是空白和卡片堆叠。

### Depth：层级、上下文与转场

- [ ] **P1** 层级是否由信息架构而不是 z-index 决定？是否明确区分页面、面板、弹层和临时提示？
- [ ] **P2** 一次是否只出现一个主要模态层？是否存在模态套模态、弹层套弹层或不可追踪的浮层链？
- [ ] **P3** 模态是否只用于需要聚焦的短任务？是否避免把完整导航和多步应用塞进弹窗？
- [ ] **P4** 弹窗、Popover、菜单是否有明显关闭方式，支持 `Esc`，并在关闭后把焦点还给触发元素？
- [ ] **P5** 转场是否保持空间和状态连续？减少动效后，变化是否仍能被理解？
- [ ] **P6** 返回、取消、关闭、撤销是否语义清楚？用户是否知道哪一个是“返回上一步”，哪一个是“放弃更改”？

### 状态、反馈与恢复

- [ ] **S1** 是否设计并实现 loading、empty、error、partial、success、disabled、offline 等边界态？
- [ ] **S2** 操作后是否立即给出与操作邻近、强度匹配的反馈？关键反馈是否不只依赖 toast？
- [ ] **S3** 加载超过短暂瞬间时，是否显示稳定的局部占位或进度？已知进度时是否使用 determinate 表达？
- [ ] **S4** 错误是否说明发生了什么、保留用户输入、给出具体恢复路径，而不是只显示错误码或“请重试”？
- [ ] **S5** 破坏性或意外不可逆操作是否在真正发生前确认？预期内的普通删除是否避免过度确认？
- [ ] **S6** 成功是否只在值得确认时强调？常规成功是否通过状态变化自然反馈，而非每次弹窗？
- [ ] **S7** 长任务是否可取消、可重试、可离开并返回查看状态？页面刷新或断网后是否还能恢复关键上下文？
- [ ] **S8** 乐观更新是否有失败回滚与可见解释？

### 撤销、拖放与输入

- [ ] **U1** 可探索、可编辑的动作是否可撤销？撤销标签能否预测将撤销什么？
- [ ] **U2** 是否支持多次撤销，并让结果在视口中可见，避免用户以为操作无效？
- [ ] **U3** 是否为相关连续修改提供批量撤销或明确的还原点？是否避免把浏览器 Back 当作 Undo？
- [ ] **I1** 拖放是否有键盘、菜单或按钮替代方案？是否支持取消和撤销？
- [ ] **I2** 拖放是否清楚表达可拖、可投放、移动还是复制，以及投放后的选中状态？
- [ ] **I3** 触摸、鼠标和键盘是否能完成同一核心任务？是否避免依赖 hover、右键或精确指针操作作为唯一入口？

### 导航、搜索与组件

- [ ] **N1** 侧边栏是否只在空间足够时长期显示，空间不足时是否转换为 drawer、顶部导航或折叠导航？层级是否不超过两层？
- [ ] **N2** 工具栏是否只放高频命令，并按导航、主操作、辅助操作分区？窄屏时优先级和 overflow 是否合理？
- [ ] **N3** 菜单标签是否是明确动词或状态？禁用、当前状态、快捷键和“需要更多输入”的省略号是否表达正确？
- [ ] **N4** 菜单是否避免多级子菜单和过长列表？相关命令是否分组，危险命令是否隔离？
- [ ] **N5** 列表行是否易扫描？标题、元数据、状态、选择态和责任动作是否一眼可分？
- [ ] **N6** 多列表格是否使用真正的表格语义、描述性列头、排序状态和键盘可操作控件？
- [ ] **N7** 图表是否有标题、单位、轴、时间范围、图例或无图例时的直接标注？是否不依赖颜色区分系列？
- [ ] **N8** 图表是否提供摘要、数据表或可访问替代？键盘与屏幕阅读器能否读取关键数据，而不只是 hover tooltip？

### 搜索与新手引导

- [ ] **Q1** 如果搜索是核心任务，是否有唯一、可发现的主入口？搜索范围是否清楚？
- [ ] **Q2** 搜索结果、无结果、拼写纠正、最近搜索和清除历史是否符合隐私预期？
- [ ] **Q3** 搜索状态是否进入 URL、Back/Forward 或可分享状态，并在刷新后保留？
- [ ] **Q4** 新手引导是否短、可跳过、能在上下文中学习，并记住用户已经跳过？
- [ ] **Q5** 是否用合理默认值和示例内容让用户先完成任务，而不是先做配置、看多页 tour 或授权？

### Web 无障碍与适配

- [ ] **W1** 键盘可以完成主任务，焦点可见、顺序合理，弹层关闭后焦点回到触发处。
- [ ] **W2** 使用语义 HTML；只在原生元素无法表达时使用 ARIA，并提供可访问名称、角色和状态。
- [ ] **W3** 动态状态通过适当的 live region、`aria-busy` 或状态文本播报，不造成重复轰炸。
- [ ] **W4** 尊重 `prefers-reduced-motion`、`prefers-color-scheme`、`prefers-contrast` 与 `forced-colors`。
- [ ] **W5** 触控目标至少约 24 CSS px，推荐 44 CSS px；目标间距足够，不误触相邻动作。
- [ ] **W6** 在 320 CSS px 宽、200% 缩放、长中文/英文和不同字体设置下仍可完成主任务。
- [ ] **W7** 浏览器原生行为不被破坏：URL、Back/Forward、表单、复制粘贴、缩放手势、新标签打开和系统快捷键。
- [ ] **W8** 用户数据收集、权限请求和自动化行为透明、最小化，不使用暗黑模式或误导性确认。

## 常见反模式

- 把“Apple 式”理解成大量玻璃、模糊、圆角、阴影和 spring 动画。
- 每个交互都加动画，尤其让高频操作等待动画完成。
- 用低对比灰字、浅色小字号和留白制造“高级感”，牺牲可读性。
- 用图标替代所有文字，没有 tooltip、可见标签和可访问名称。
- 把核心功能藏进 overflow、`...` 或右键菜单，首屏只剩装饰和口号。
- 用 modal 做导航，或在 modal 中再造一个完整应用。
- 弹窗、菜单、Popover 相互叠加，关闭后焦点丢失。
- 用 toast 承载错误、数据丢失和需要用户决策的关键信息。
- 仅靠颜色表达成功、失败、选中、风险或图表系列。
- 让拖放、hover、右键或精确指针成为唯一操作方式。
- 把浏览器 Back 当作 Undo，或刷新后丢失工作上下文。
- 照搬 macOS 窗口按钮、iOS 导航栏、Dynamic Island、SF Symbols 或平台专属手势。
- 用首启多页 tour 阻塞主任务，并每次重新展示用户已跳过或关闭的内容。
- 为了视觉一致性强制覆盖系统深色模式、对比度、缩放和减弱动态偏好。

## 输出要求

设计建议应说明用户目标、层级决策、状态策略与 Web 实现约束。Review 结果先列 P0/P1，再列 P2/P3；先列阻断问题，再列打磨建议。不要因为页面“看起来像 Apple”就通过，必须让每项结论能对应到具体证据和用户影响。