前言

色彩系统的设计是很有趣的事，总有一种常做常新的奇妙新鲜感，随着设计理念的演进、相关设计工具的出现，每隔一段时间笔者去探索实践色彩系统设计时，总能发现一些新玩意，并将其引入到设计流程中，实践更高效科学的构建方式。

ps: 本文不涉及前期的品牌色定义、色系选择、搭配等流程，我们将聚焦色彩系统中最重要的生产与落地环节，分析现状与问题，引入无障碍标准和新工具，构建科学的色彩系统。

定义优秀的色彩系统

在开始介绍如何设计色彩系统前，我们先简单定义一下什么是优秀的色彩系统，明确以下四个标准可以为我们后续搭建过程中的设计决策提供清晰可靠的判断依据。

01. 易生产

生产成本其实是对色彩系统内部复杂度的反映：生产成本和复杂度更低的系统通常更有序、具备更强的一致性，并且往往能通过程序或工具实现自动化生产。

02.易维护

随着需求迭代、产品升级，色彩系统也需要随之动态调整，最常见的就是增加新的颜色。色彩系统的可维护性是让其保持活力的重要保障，也是系统健壮性和可靠性的最好的体现。

03.易上手

除了使用准确的语义别名、精简的颜色类型等帮助设计师快速上手整个色彩系统外，当通过 Design Tokens 连接设计与开发时，开发人员也成了色彩系统的用户，因此色彩系统应为所有人而设计，即使没有专业背景也可以学习和理解。

04.符合无障碍设计

随着无障碍设计受到从业者越来越多的关注，颜色作为产品的视觉无障碍的重要部分，色彩系统中相关语义别名的颜色之间的对比度需匹配 WCAG 对比度标准，以保证界面上视觉元素的可辨识度。

▲ 图片来源于网络

创建色彩系统

色彩系统通常会包含两部分：

一、Color Palette（基础色板）

由主色、辅色、中性色等颜色生成的梯度色组成，是产品内所有可能使用颜色的最大集合，整个色彩系统的底层基础；

二、Color Scheme（配色方案）

从基础色板中选取合适的颜色，根据该颜色在产品界面中实际使用的场景对其命名，也就是为颜色创建 Semantic Alias（语义化别名），配色方案是整个色彩系统的核心，也是我们日常设计工作中实际使用的部分。

▲ 通过一个 key color 生成 palette，将 palette 中的颜色使用语义重新命名，明确其应用范围构成我们在设计工作中使用的 scheme。

基础色板与配色方案的组合应该是适用面最广的最佳实践，但色彩系统的结构不是死板的，需要根据实际需求出发进行调整和取舍，像精简、敏捷的个人项目只需要配色方案即可，但如果面向灵活、庞大的组件系统，可能除了基础色板与配色方案之外，还需要在往上架设一层 Component-Specific Color Scheme (组件配色方案) 实现更多定制的能力。

Step.1

创建 Color Palette（基础色板）

· 为什么使用 HCT 色彩空间代替传统的 HSV/HSL

· 如何将基础色板导入 Figma

1.1 HSV/HSL 色彩空间的局限

创建基础色板的方式和工具有很多，最常见的应该是基于 HSV/HSL 色彩空间，为 H、S、V 三个参数分别设定数值范围与插值曲线，从而生成一组梯度色的方法，大部分一键生成色板的工具均基于此原理，如 ColorBox 就是其中非常有代表性也非常实用的色板生成工具，想必很多设计师也都使用过。但是，这个使用范围最广，接受度最高设计方法本身存在一个致命的问题，那便是使用了「错误的」色彩空间。

▲ ColorBox 是基于 Lyft 团队的开源算法上线的 Web 工具，其原理是为颜色的 hue、saturation、value 分别设定数值范围（Rang）和插值曲线（Curve），相当于创造了一条在 H S V 三维空间内的连续曲线，而最后输出的色板就是设定的梯度序列在曲线上的取色的集合。

为什么说我们常用的创建色板的设计方法使用了「错误的」色彩空间？首先要从 HSV/HSL 色彩空间在表达色彩亮度时存在的问题说起。

作为设计师应该都会有类似的经验，相同 Saturation（饱和度） 和 Value（亮度）的色彩，在不同的 Hue （色相）上的亮度感知是完全不一样的，其原因是 HSV/HSL 色彩空间是应用于数字化图像处理领域，为了方便机器理解、计算、呈现而设计，是人类视觉的线性模型，但人类的感知却是非线性的，所以造成数值与感知不匹配的问题。

▲ 相同 saturation（饱和度） 和 value（亮度）数值，在不同的 hue（色相）上视觉感知的亮度完全不同，其实际的亮度与其下方对应的灰阶更为接近。

其次要理解彩系统中色彩亮度的意味着什么？

我们后续在设计配色方案时，需保证相关语义别名的颜色之间对比度符合 WCAG 标准，如内容与背景的颜色之间对比度需到 4.5 以上，而对比度的本质是两个颜色之间感知亮度的差异。

毫无夸张的说，色彩系统的本质是围绕亮度组合的设计，但是颜色的数值本身不提供任何与感知亮度相关的信息，我们也无法直接从两个颜色的数值上判断出他们的亮度差异（即对比度）。

▲ 如果不借助对比度检测工具，我们很难从梯度色中为次级文本选取符合无障碍标准的颜色

最后，基于上述问题，我们可以还原一下设计师在搭建色彩系统时的真实情景与坎坷遭遇。因为HSV/HSL 颜色数值与人类的视觉感知亮度不匹配，导致我们如果使用相同参数生成的色板在不同色相上整体呈现的亮度差异很大，为了相对和谐的色彩搭配效果，那么必须要设计师的额外介入，耗费时间和精力手动调整参数，而且这个过程全凭设计师的主观判断，主观判断便意味着非标准化。

即便设计师调教了一组相对和谐的基础色板，为了使配色方案中颜色的搭配符合 WCAG 对比度标准，还需要设计师对用到的颜色反复做对比度检查。

很快设计师就会陷入来回修改，不断拉扯的境地，特别是对于一些非常纠结的设计师来说简直是一场令人身心俱疲的噩梦。

1.2 全新的 HCT 色彩空间

既然 HSV/HSL 色彩空间的颜色亮度数值与视觉感知无法匹配，那么是否存在以人类视觉感知角度开发的色彩空间？

答案当然是肯定的，早在 1976 年国际照明委员会就定义了 CIELAB （Lab*）色彩空间，旨在提供一个与人类感知统一的空间，除此之外，还有还有一系列基于 CIELAB 演化而来的色彩空间，如 LCH、OkLab、HCT 等。

在这些色彩空间中，笔者非常推荐 HCT，这也是目前我在项目实践中使用的方案。

▲ Lab、LCH、OkLab、HCT 色值，其中标重的数值为亮度，其颜色的亮度与实际感知统一

HCT 是 Google 为了更好的色彩呈现，以及更方便的通过程序自动生成色彩，而发明的「全新」色彩空间：H 即 Hue 色相；C 即 Chroma 色度，可以理解为色彩浓度；T 即 Tone 光度，也就是亮度 。

▲ HCT 由 hue、chroma、tone 构成，hue 与 chroma 来自 CIMA16，tone 来自 Lab 的 L｜图片来自 Designing Harmony into Dynamic Color

如果读者查阅过 Material Design 3 的色彩规范部分，那么对 HCT 应该不会陌生，作为和新规范一起推出的色彩空间，HCT 是 Android 12 上 Dynamic Color （动态主题）背后的关键技术之一。

那么我们如何使用 HCT 色彩空间生成色板？Google 在上线新规范的同时也上线了 Material Theme Builder 工具，只需输入一个颜色便可以一步到位，自动生成包含基础色板与配色方案的色彩系统，还可以直接导出相关代码。Material Theme Builder 有网页版与 Figma 插件版，使用非常方便。

▲ Material Theme Builder ｜ 图片来源 Figma community

但 Material Theme Builder 无法完成除定义颜色以外的任何调整，比如说增减或自定义色板梯度，没办法