设计和用户界面变更

在贡献或审查设计和用户界面（UI）变更时，请遵循以下指南。有关代码审查的更广泛建议和最佳实践，请参阅我们的 代码审查指南。

这些指南的基础是 Pajamas，即 GitLab 的设计系统。我们鼓励您通过添加和改进来 为 Pajamas 做贡献。

合并请求审查

作为合并请求（MR）的作者，您必须：

• 在描述中包含变更的 Before 和 After 截图（或视频），如我们的 MR 工作流程 中所述。这些截图/视频对所有审查者都非常有帮助，可以加快审查过程，特别是当变更较小时。
• 为任何面向用户的变更的合并请求附加 ~UX 标签。这将触发我们的审查者轮盘（Reviewer Roulette）来建议一位 UX 审查者。

如果您是 团队成员：我们建议将 审查者轮盘 建议的产品设计师指派为审查者。这有助于我们 均衡分配工作、改善沟通，并使我们的 UI 更加一致。如果您有理由选择其他审查者，请添加评论说明您指派了自己选择的产品设计师。

如果您是 社区贡献者：我们倾向于选择在您贡献领域是 领域专家 的产品设计师，而不考虑审查者轮盘。

检查清单

在 设计 和 审查 UI 变更时，请检查这些方面。

文本

• 将 Pajamas 作为 UI 文本的主要指南，将 文档风格指南 作为次要指南。
• 使用清晰一致的术语。
• 检查语法和拼写。
• 考虑帮助内容并遵循其 指南。
• 请求 合适的 Technical Writer 进行审查，指明他们应审查的具体文件或行，以及如何从用户角度预览或理解文本的位置/上下文。

模式

• 考虑产品中使用的类似模式，并在偏离时在问题中说明理由。
• 使用合适的 组件 和 数据可视化。

视觉设计

使用浏览器的元素检查器检查视觉设计属性（Chrome、Firefox）。

• 设计系统提供了在支持模式下工作的 design tokens 和 组件。
• 使用基于语义含义的推荐 颜色 作为设计统一产品体验的一部分。这些颜色组合在所有模式下都受支持。
• 遵循 排版指南。
• 遵循 布局指南。
• 使用现有的 图标 和 插图，或根据 图标设计 和 插图创建指南 提出新图标。
• 考虑所有 支持的模式。
  • 设计系统提供了在支持模式下工作的 design tokens 和 组件。
  • 当模式是客户结果的主要因素时，要格外小心。
• 深色模式设计必须符合 深色模式原则。

状态

使用浏览器的 样式检查器 检查状态，以切换 CSS 伪类如 :hover 等（Chrome、Firefox）。

• 考虑所有适用的状态（错误、静止、加载、焦点、悬停、选中、禁用）。
• 考虑依赖于数据大小的状态（空状态、部分数据和大量数据）。
• 考虑依赖于用户角色、用户偏好和订阅的状态。
• 考虑动画和过渡效果，并遵循其 指南。

响应式

使用浏览器的 响应式模式 检查响应式行为（Chrome、Firefox）。

• 考虑所有断点上的元素调整大小、折叠、移动或换行（即使优先考虑较大的视口）。
• 在所有断点中提供相同的信息和操作。

可访问性

使用浏览器的 可访问性检查器 检查可访问性（Chrome、Firefox）。

• 根据我们的 合规声明，符合万维网联盟（W3C）Web 内容可访问性指南 2.1 的 AA 级。
• 遵循可访问性 Pajamas 最佳实践，并阅读可访问性开发者文档的 检查清单。

交接

当设计就绪后，_在_开始实施之前：

• 在相关问题中分享设计规范，最好通过 Figma 链接 或 GitLab Designs 功能。请参阅 何时使用每种工具。
• 记录用户流程和状态（例如，使用 Markdown 中的 Mermaid 流程图）。
• 记录 design tokens（例如使用 Figma 中的 design token 注释）。
• 记录动画和过渡效果。
• 记录响应式行为。
• 记录不明显的行为（例如，字段自动聚焦）。
• 记录可访问性行为（例如，使用 Figma 中的可访问性注释）。
• 为 GitLab SVGs 项目贡献新的图标或插图。

后续工作

在任何时候，但通常 在 设计实施期间或之后：

• 为设计系统的添加或改进贡献 问题到 Pajamas。
• 使用 ~Deferred UX 标签创建问题，用于因时间或可行性挑战而有意偏离商定的 UX 要求的情况，并链接回相应的问题或合并请求。
• 为超出商定 UX 要求的 功能添加或改进 创建问题，以避免范围蔓延。