若何更好的统一颜色规范？这个方法正在成为新趋势

Hi，我是彩云。
咱们平时在做UI组件库的时候，会碰着一个问题，定义了很多颜色但在团队互助的时候，却依然还是会根据每个设计师自己的喜好来配色，很难将颜色规范很好的统一起来。

这个中有一个很严重的问题便是对付颜色的命名和管理不足清晰，那么本日这篇文章通过一个国外大厂真实的颜色组件升级案例，希望能帮你办理这个难题。

我们花了几个月的韶光改进了设计系统 Cobalt 中颜色的处理办法。
颜色是 UI 的基本元素：它们构成视觉措辞，帮助定义品牌，并被开拓和设计师每天用在产品设计中。

但如果我们在利用颜色上没有明确的辅导原则，如颜色被团队中的设计师按喜好利用时，将会导致产品看起来非常混乱。

我们APP中的不一致例子

接下来我会见告你，我们是如何做好颜色规范以及在全体项目中面临的寻衅，正如你将看到的，这个项目并不像看上去那么大略：

如何通过 Getaround 在设计和技能方面管理颜色概述这个别系的局限性，并解释我们如何改进它什么是语义颜色我们是如何实现它的，以及它带来的上风！

一、我们之前在Getaround中如何管理颜色？1. 在设计方面

和许多设计团队一样，我们利用 Figma 作为我们的紧张设计工具。
我们的颜色被放在“根本”库中，可以在个中找到我们在产品中利用的所有常见样式，例如字体样式、颜色、图标等。
这个库供应了我们每天利用的专用系统库（iOS、Android、Web、电子邮件）。
颜色名称过去是基于它们的外不雅观。
例如：紫色颜色是我们的紧张颜色，而石墨色是基本文本的常规颜色。

2. 在技能方面

在我们的APP中，曾经会用相同的系统来管理颜色。
此外，还有一些语义颜色，但仅限于 iOS，开拓用的也不多。

二、我们在旧系统中面临的限定

在利用这个别系时，团队反复面临同样的问题：如何确保从一位设计师到另一位设计师以相同的办法利用颜色？如果没有适当的辅导原则，我们如何确保开拓很好的还原？如果来日诰日我们必须用全新的配色方案来改造我们的品牌，要怎么快速统一？让我们试着找出我们是如何陷入这种田地的？

1. 没有明确的颜色利用规范

所有设计师都利用相同的色板，但自 2019 年 Getaround 品牌重塑以来，除了引入不一致之外，没有明确关于如何利用它们的规范，以是设计师在选择颜色时迷失落了方向。
然后他们将开始建立自己的参考资料，每个设计师都有不同的配色想法。

例如：设计师该当在所有这些灰色阴影中为次级文本选择哪种灰色？颜色命名在这里不是很有帮助

2. 旧品牌的设计包袱

以前品牌的一些旧颜色仍在利用（按钮上的蓝色阴影，标题……）。
到现在也没有真正的行动操持来迭代它们。

旧驱动器品牌

三、我们对新系统的设想

在 2021 年初，我们有机会为我们的 iOS 和 Android APP来制订长期的 UI 方案。
我们问自己“5年后我们的APP会是什么样的？”。
我们会回顾， Getaround 品牌是如何成为我们视觉方法中央的。

以上是我们品牌和设计团队在 2020 年完成的全面事情的一小部分致力于设计系统的 Cobalt 团队借此机会重新考虑了颜色系统。
然而，为了使这一目标成为现实，我们面临着一些寻衅：

1. 制订辅导原则

我们如何确保每个设计师都可以依赖易于理解和利用色彩系统？拥有一个大略系统将加快利用速率。

2. 颜色能通过可用性标准

我们如何确保从一开始就设计出易于利用的颜色？

3. 易于掩护并符合未来趋势

我们如何才能使系统易于掩护并符合现在和未来的行业标准（例如：暗模式）

四、我们新的颜色系统：语义颜色

在我们的探索阶段，在 Figma 的共享环境中事情匆匆使我们保存和记录我们所做的设计决策。
就像我们该当如何命名我们的强调色：（紧张？强调？）我们还测试了APP界面在阴郁模式下的外不雅观，以及如何精确支持这一点。
我们该当创建一个单独的调色板还是为每个组件都创建一个深色版本？

我们开始与开拓谈论这个问题，以理解他们有什么办理方案来处理这些问题。
语义颜色的观点很快就被开拓职员提出来，由于他们知道并且很好地利用了这个观点。
但对付设计师来说，又要如何准确理解呢？

1. 什么是语义颜色？

语义指的是根据颜色的利用办法而不是色调来命名颜色的方法。

例如，你可以将颜色命名为“成功”或“积极”，由于它指的是含义，而不是“绿色”或“翡翠绿”。
乃至可以根据颜色在屏幕上的运用办法来命名颜色，例如背景颜色、按钮背景颜色、文本质彩、图标颜色等……

2. 从基于外不雅观的配色方案到基于语义的配色方案

语义颜色并不新鲜，越来越多的产品开始采取这种办法来定义颜色。
我们可以从下面一些大厂的颜色规范来学习google

https://material.io/design/color/the-color-system.html#color-theme-creationApplehttps://developer.apple.com/design/human-interface-guidelines/ios/visual-design/colorShopifyhttps://polaris.shopify.com/design/colors#navigationAsanahttps://polaris.shopify.com/design/colors#navigation

显然，这种颜色系统有很多优点。
因此，现在让我阐明一下我们如何在实践中将这个观点运用到我们的产品中。

3. 深入研究语义颜色

我们的新颜色系统由两部分组成：

根本调

我们与品牌团队密切互助，他们定义了一个全新的品牌，我们在事情时会环绕这个品牌考虑。
该品牌的每种颜色都采取多种色调进行调度，以创造更大的灵巧性，一次构建成为根本调色板。
它代表可以在产品中显示的所有可能颜色。
团队可能不会全部利用它们，但他们会选择在产品中效果最好的那些。

根本调色板

4. 语义颜色

语义颜色建立在用作参考的根本调色板之上。
正如我之前阐明的，命名不再是指颜色的“外不雅观”（洋赤色、棕色、绿色……），而是指UI 元素它们被运用于（文本、图标、按钮、背景……）以及该元素的状态（活动、非活动、成功……）。
请参阅此处的命名法和一些示例：

语义颜色构造和示例这意味着来自根本调色板的颜色可以用于多种语义颜色：

这便是我们根据这个新原则重新调度颜色命名的办法：

我们通过设计师和开拓进行了内部用户测试，以确定命名语义颜色的最佳办法。
我们考试测验了很多不同的命名方法，创造过于详细的命名系统对付我们的团队和产品的规模来说掩护和利用太繁芜了。
我们决定做一些大略的掩护，同时在命名方面有足够的延展性。

五、语义颜色的好处1. 语义色彩嵌入设计原则

语义颜色侧重于颜色的用场。
它肃清了设计师和开拓对利用什么颜色的盲目预测，由于视觉措辞直接传达了设计决策。

例如：在这里，颜色命名使设计师更随意马虎做出精确的选择。
在我们的原则中， Accent state 用于交互元素。

2. 解锁阴郁模式

语义颜色可以适应不同的主题。
语义颜色的名称始终相同，但它的外不雅观可能会根据所选模式而改变。
例如，语义颜色“主背景”可以指浅模式下的“白色”和深色模式下的“玄色 500”。
根据用户选择的模式，将自动显示精确的颜色。
这对我们的设计系统来说是一个真正的游戏规则改变者，由于它将使它更加面向未来。

明暗模式下的语义颜色 Primary.Background

3. 语义颜色高效灵巧

如果我们将来要更新颜色，利用语义颜色也会变得更随意马虎。
假设我们想要将我们的主色变动为蓝色。
我们只须要将根本调色板中的“紫色”更新为“蓝色”。
与该颜色干系的所有语义颜色也将神奇地更新。
另一种情形可能是更新特定 UI 元素的颜色，例如按钮，而无需触摸利用紫色颜色的其他元素。

在这种情形下，我们只须要更新 ButtonBackground.Primary 颜色，非常大略。
如果没有该系统，更新颜色将须要经由大量 QA 以确保将变动运用到任何地方。

4. 颜色组合指南

这个别系彷佛很随意马虎利用，但设计师仍旧有一些问题：

我什么时候可以利用正常笔墨颜色？我什么时候可以利用次级文本质彩？我什么时候可以利用可交互颜色？

为了帮助设计师选择颜色，我们创建了一个交互式指南，列出了所有可能的颜色组合。
我们在 figma 原型中创建了这个辅导原则，每次变动设计系统颜色时都会更新该规范。
它突出了许可的语义颜色组合，以最大限度地保持同等性。

点击可以查看大图Figma 中内置的语义色彩交互指南

5. 结果

采取这种新的颜色系统产生了一些变革：

1）我们从“Foundation”库中提取颜色，并将它们分为深色和浅色模式。
这一举措使我们能够利用 Figma 开关功能轻松地将设计文件从 Light 切换到 Dark 模式。
这也使库更轻且更易于掩护。

2）语义颜色已在我们的 iOS 和 Android 运用程序上成功实现，我们现在正在努力在我们网络平台上利用相同的系统。
我们很快就会有一个集中的配色方案来处理所有系统上的颜色。

总结

总结下本日学到的内容：

创造并准确描述团队在利用颜色时碰着的问题如何从提出设想，到以新的办法来定义颜色如何通过语义化颜色来使得大家更方便的利用颜色，我们也可以在自己的组件库中多利用语义化的颜色来进行命名管理，这样团队协作才会更加高效。

（授权截图）

作者：Fabien Gavinet，译者：彩云Sky

原文链接：https://medium.com/getaround-eu/colors-that-make-sense-505d0f3509c1

本文由 @彩云Sky 翻译发布于大家都是产品经理，未经容许，禁止转载。

题图来自Unsplash，基于CC0协议。