design-better-interfaces

设计更好的界面

将界面视为完整的产品工作流。将此质量关卡作为设计决策和完成工作的唯一标准。先确保任务、信息、状态和行为，再改善外观。

使用当前环境中可用的检查、渲染、浏览器、截图、无障碍和测试能力。

选择请求类型

选择一个分支，并遵循其路径：

• 审查或诊断： 简述 → 检查 → 梳理 → 状态/风险 → 验证 → 报告。 保持产物不变。结束时，将所有适用关卡标记为已通过、未通过或未验证，并按对用户的影响排序列出发现。
• 设计或探索： 简述 → 检查（存在产物时）→ 梳理 → 决策 → 状态/风险 → 报告。默认产出一个连贯的方向。用户要求提供多个方案时，确保方案在层级、交互或布局上有实质差异。明确权衡并推荐一个方向后结束，除非用户要求中立对比。
• 构建、优化或修复： 简述 → 检查 → 梳理 → 决策 → 状态/风险 → 实施 → 验证 → 报告。完成所请求的范围、确保主要任务在测试条件下成功，并为所有适用关卡提供证据后结束。报告阻碍结果通过的外部因素。

将对外发布视为单独的操作，必须由用户明确提出。

1. 明确需求

根据现有证据确定：

• 用户、主要任务、使用频率、错误代价和可见的成功标准；
• 领域、品牌、语气、预期信息密度和注意力预算；
• 受影响的界面、目标尺寸和平台、输入方式、主题、设计系统及技术限制；
• 数据状态、权限、内容边界，以及实时或定时行为。

提问前先调查产品和代码仓库。如果缺失的选择会实质性改变产品，就提出问题；否则说明合理的假设。

每项内容都已明确、不适用或由明确假设涵盖后，即完成此步骤。

2. 检查产品

对于现有产品：

1. 阅读项目说明并走查受影响的流程。
2. 梳理设计令牌、组件系列、字体排印、间距、信息密度、导航、术语、交互和平台变体。
3. 使用真实数据在相关尺寸下捕获渲染基线。
4. 用用户可见的方式描述观察到的问题。

复用合适的惯例。对于无法访问或有害的惯例，替换为最接近且连贯的方案。

对于全新界面，根据受众、领域、内容、任务和预期信息密度确定视觉方向。

记录当前流程、适用惯例、观察到的问题和基线后，即完成此步骤。如果环境无法生成渲染结果，则将渲染标记为未验证。对于全新项目，若方向以需求为依据，且现有产物检查已标记为不适用，即完成此步骤。

3. 地图保留与界面

在更改现有界面之前，先编写保留约定：

• 必须保持清晰可辨的信息和层级；
• 必须保持等效的任务、交互、快捷方式和替代入口；
• 用户依赖的稳定位置或几何布局；
• 必须在更改后保留的产品惯例和语义含义。

梳理所有受影响的界面：

• 页面、重复行、工具栏、菜单、对话框、横幅、工具提示、门户、叠加层，以及嵌入式或第三方内容；
• 小、中、大尺寸；支持的平台和主题；
• 指针、键盘和触控；
• 正常、过长、空、加载中、错误、过时、禁用、权限受限、已选中、已折叠、已筛选和已分页状态。

对于大范围改版、叠加层、自定义控件、响应式或跨平台工作、实时或定时状态，或筛选／折叠／分页，请阅读并应用 references/interface-failure-checklist.md 中的相关章节。

完成此步骤的标准：每项约定都有计划中的验证方式，且每个适用的界面与状态组合都已列出或明确排除。

4. 通过质量门槛做出决策

按以下优先顺序执行：

1. 用户能够完成主要任务。
2. 状态、层级和下一步操作清晰明确。
3. 如实呈现风险、失败、恢复和可逆性。
4. 结果与产品和设计系统协调一致。
5. 结果在支持的尺寸、输入方式、主题和平台上均可访问且稳健。
6. 保持空间稳定性和运行时性能。
7. 视觉设计精心斟酌，且适合其领域。

只有在所有更高优先级的标准均得到满足时，较低优先级的改进才算通过。

围绕主要目标来构建界面：

• 让关键状态和可能的下一步操作易于找到。
• 降低辅助上下文的权重，并提供有力的默认选项，同时提供相关替代方案。
• 让界面复杂度与任务复杂度相匹配：用表格进行比较，用序列呈现线性工作，用空间界面处理空间类工作。
• 优先考虑易于理解，而非信息压缩；在缩短标签或隐藏上下文之前，先移除不会影响决策的信息。
• 逐步展示次要细节，并为不熟悉的操作添加标签。
• 在悬停、选择和实时更新期间，保持常用目标的位置稳定。
• 仅在装饰性元素有助于呈现层级、状态、可供性、内容或品牌含义时使用。

完成此步骤的标准：主要目标、操作层级、信息结构、组件策略、响应式行为和视觉设计依据都清晰明确，并且与项目简述和保留约定一致。

5. 定义状态、转换和风险

考虑所有适用的生命周期状态：初始、已填充、加载中、进度、空、首次使用、部分、过时、离线、验证、错误、重试、恢复、成功、已禁用、权限受限、冲突、乐观更新、回滚、取消、过期和卸载。

对于每种可见状态，指定唯一的权威来源，并确保渲染、布局、无障碍描述和副作用都使用同一推导结果。定义多个状态同时出现时的优先级。在概念上区分领域状态、待处理事项和装饰状态。

为每个控件定义行为。操作得到确认后再显示成功状态。区分草稿、预览、已保存、已应用、已发布、部分完成和失败状态。确保活动项可通过筛选器、分页和折叠分组访问。根据领域事实推导空状态，而不只是根据渲染出来的内容切片推导。

根据影响范围、后果和可逆性对每项变更进行分类：

• 直接执行本地可逆操作，并在可行时提供撤销功能。
• 对影响范围广但可逆的更改，明确其范围并允许用户检查。
• 对具有破坏性、成本高、会影响外部或难以撤销的操作，显示确切目标、当前影响范围和后果，并要求用户在当前操作情境中确认。
• 让警告可采取行动，并提供恢复方式或明确的继续操作路径。

当每项主要操作都有负责方、目标位置、反馈、退出路径、失败行为、恢复路径和可验证的最终状态，且每个不适用的状态都标明原因时，即可完成此步骤。

6. 实现一条纵向切片

在请求范围内完成一条可用路径：

• 复用设计令牌、组件、产品用语和交互语义。
• 对操作的每个入口应用相同的资格和权限检查。
• 使用语义化结构，避免交互角色嵌套，并确保名称易于访问、支持键盘操作、焦点可见、对比度和目标尺寸充足、支持减少动态效果且文字易读。
• 为每个连续界面指定唯一的背景、边框、阴影、模糊、裁剪和安全区域行为负责人。共享基础组件接管后，移除已过时的局部补偿。
• 将叠加层视为一个系统来处理：锚点、宽度、碰撞、裁剪、焦点、Escape、点击外部、滚动以及对底层内容的遮挡。
• 定义响应式约束，确保在中间宽度下也不会发生裁剪、重叠、溢出和布局偏移，而不只是针对指定断点。
• 在请求范围内测试真实内容、长字符串、空数据、极端值和本地化压力。

当主要任务的正常路径已在代码中可用，并且上一阶段定义的每种适用异常状态都已实现时，即可完成此步骤。

7. 使用渲染结果进行验证

使用现有最强能力，根据渲染后的产物判断视觉质量。静态检查无法证明视觉质量、响应行为或交互正确性。

使用产品支持的视口。如果未定义视口，请检查 375、768 和 1440 CSS 像素的视口、每个布局转换点附近的一个中间宽度，以及 320 像素宽度下的水平溢出情况。

完成前：

1. 使用相同的数据、视口和主题比较修改前后的结果。
2. 使用所有受支持的输入方式完成主要流程。
3. 检查所有适用的状态、状态转换、反向操作和高风险变更。
4. 检查层级、对齐、间距、裁切、重叠、换行、焦点、悬停、激活、禁用、滚动行为和空间稳定性。
5. 使用小、中、大宽度以及极端内容进行测试。
6. 检查无障碍名称、焦点顺序、对比度、语义、减少动态效果、强制颜色，以及适用的平台或浏览器回退方案。
7. 同时检查叠加层、其触发器和底层内容。
8. 审查同类组件系列的几何尺寸、视觉尺寸、行为和令牌偏差。
9. 检查运行时错误，并运行相关的构建、类型、lint 和测试验证。

视觉变更使用截图，动态或定时行为使用简短录屏，依赖平台的工作使用目标设备证据。如果无法使用目标硬件或受支持的浏览器，请标记为 unverified，而不要推断为成功。

将每项适用检查记录为已通过、失败或未验证。对于未验证的检查，执行最接近的可行检查，并说明限制。

当每项保留要求和适用的界面状态组合都有证据时，即可完成此步骤。修正范围内的失败项，或报告阻碍因素；将审查失败项转化为按优先级排列的问题。

8. 报告证据

开头说明结果。说明变更或发现、观察到的问题、重要设计选择、受影响的界面或文件、保留结果、已通过的检查，以及任何失败或未验证的项目。

当报告内容完整自洽、所有未解决的问题均已标注，并且当前任务中仍可执行的验证均已完成时，即可完成此步骤。