本文分享個人搭建青云 QingCloud 可視化色彩體系過程中的一些經(jīng)驗。（閱讀此文需要一定的色彩空間知識作為基礎，否則有些難啃）

一、前言

1. 背景

目前平臺上使用了三套組件庫 A、B、C，A 是最原始的組件庫，基于此擴展了 B 組件庫，并對顏色進行了改進，C 是全新的組件庫，引用了 Token 及其他新的前端技術棧。三套組件庫獨立存在，應用在龐大的云平臺各個業(yè)務產品中，發(fā)展趨勢為使用 C 組件庫開發(fā)日后新的業(yè)務，并逐步替換老的業(yè)務。

關于顏色，B 組件庫采用 HSB 色彩空間調色并進行人工調整，C 組件庫沿用 B 組件庫的色板并對部分顏色進行了優(yōu)化。

關于可視化組件，平臺使用第三方開源圖表庫 Echarts 進行簡單定制化。

目前的需求是基于 Echarts 系統(tǒng)化定制出一套圖表類型較全面、交互較統(tǒng)一、使用規(guī)范較明確的可視化組件庫。因此，確定一套可視化顏色系統(tǒng)成為當務之急，經(jīng)過簡單的調研得出兩套解決方案：

1. 方案一：沿用組件庫 C 的顏色；
2. 方案二：基于適用于可視化場景的色彩空間確定一套全新的顏色。

不難判斷的是，采用方案一，要面臨的問題就是：

1. 色彩空間落后，不適用于可視化場景；
2. 大量人工調整，無法滿足日后自動化交付場景所需；
3. 相關算法及推導過程丟失，設計側無法進行科學化、可持續(xù)化迭代。

且在調研過程中我們發(fā)現(xiàn)，可視化色彩與設計系統(tǒng)色彩并無必要的理由進行捆綁：

1. 一方面，可視化場景對色彩的要求要遠高于設計系統(tǒng)組件庫，因其主要通過顏色來識別數(shù)據(jù)差異，所以，對顏色的亮度、對比度、色差、和諧度等要求非常高；
2. 另一方面，可視化組件庫的適用產品類型通常是多種多樣的，夸張點講就是任何類型的產品中都可能會用到可視化。這一點就需要可視化組件庫擁有很強的風格兼容性，這就導致了其顏色必須兼容性強，并非隨便拿一套設計系統(tǒng)色彩過來就能滿足的；
3. 設計系統(tǒng)中的顏色使用場景與可視化中的顏色使用場景不同，這就導致很多已經(jīng)成型的設計系統(tǒng)色彩從設計之初的（設計目標）就不適合拿來做可視化設計；
4. 再向底層去挖掘，很多設計系統(tǒng)的色彩空間不適合可視化場景，這會導致相關擴展色板的推導流程甚至主題演變流程變得異常困難。

最終，我們采用了方案二，也就有了接下來要發(fā)生的事情。但在開始之前，我們需要想清楚幾個問題。

2. 理想的可視化色彩特點是什么？

看待這個問題，其實我們要搞清楚的是可視化場景對顏色的要求是什么？

① 保證同色相或不同色相之間的辨識度與色差是基本要求

可以毫不夸張的說，可視化系統(tǒng)就是一個色彩系統(tǒng)，無論多么復雜花樣繁多的圖表，都要依靠顏色去表達。而在眾多表達手法中，顏色與顏色之間的對比是最常使用的。

② 顏色所傳達出來的感覺要準確

眾所周知，顏色不僅僅能表達人類的情緒，如熱鬧、喜慶、冷淡、沉穩(wěn)。還能表達事物的特征，如溫度冷暖、海拔高低、數(shù)據(jù)升降。

③ 充分考慮色盲色弱等視障群體的使用體驗

我們在產品設計過程中經(jīng)常會提到無障礙設計，也通常會在設計系統(tǒng)中對顏色對比度、字體大小等做一些驗證，也會充分考慮用戶設備情況及產品使用環(huán)境做一些針對性設計。在可視化設計中，這些驗證是相通的。

④ 顏色的生成、演變與應用是動態(tài)的

前面我們提到過，無論是產品迭代還是純視覺升級亦或產品交付自動化，從技術架構到顏色算法在設計之初都要充分考慮擴展性。以至于在可視化設計中，色環(huán)的確定、色板的生成、色彩的搭配、色序的應用等都要保證有理有據(jù)且靈活可變，充分兼容復雜極端場景。

注意，顏色算法是指通過大量實踐、總結和優(yōu)化，可以用來相對科學的批量的解決符合一定規(guī)律或映射關系的場景問題的一種途徑，其產出相對理性過程也相對高效，是做后續(xù)顏色優(yōu)化工作的基礎，可以大大降低人為干預的幾率，而非一成不變的去應用。

⑤ 顏色搭配要符合產品調性，是品牌的延續(xù)

可視化的應用場景非常廣泛，從國家生產總值到個人收支明細，大到政務系統(tǒng)小到記賬 App，都有其載體風格調性，如中立、活潑、科技等，均不能脫離于"品牌"而設計。

⑥ 保證顏色的美觀性

回到設計本身，也是設計本質---美，還是要保證的。

3. 傳統(tǒng)的色彩空間弊端是什么？

我們先來簡單看一下使用傳統(tǒng)的色彩空間是如何配色的。

此處受 @lemonoO 的啟發(fā)

最初，互聯(lián)網(wǎng)上的產品形態(tài)比較簡單，對顏色的定義僅僅局限于紅、黃、藍、綠四個語義色上，用來模擬表達成功、失敗等情緒。

在此之上，手動擴展幾個相對深與淺的顏色用于如按鈕 Hover、Active 狀態(tài)。

顏色之間依靠一些配色工具在色盤上根據(jù)對比色、互補色等原理進行搭配。

隨著互聯(lián)網(wǎng)的飛速發(fā)展，互聯(lián)網(wǎng)產品的形態(tài)逐漸復雜，組件也日趨完善，人們不斷探索能夠滿足更多使用場景的配色方案，定義相對完善的色彩體系。于是，Tint&Shade 擴展色階的方案就出現(xiàn)了。

該方案通過定義基準色后分別向深淺兩個方向疊加不同不透明度的黑色與白色來生成色階，達到擴展基礎色板的目的，典型的工具如 Tint and Shade Generator。

后來人們發(fā)現(xiàn)，這種方案雖然簡單粗暴，但依靠疊加不同量黑色與白色生成的色階存在一些問題或不滿足使用場景，如首尾丟色嚴重，無法通過色相偏移的方式制造冷暖效果等。

于是，基于更符合人類認知的色彩空間如 HSB、HSL 生成色階法就誕生了，并成為至今使用范圍最廣的方案。

以 HSL 為例，該方案通過將顏色定義為符合人類認知的三個變量：色相、飽和度、亮度，分別進行控制并靈活調配，如固定飽和度與亮度，在色環(huán)上通過改變色相生成基礎色。

或固定色相與飽和度，通過調整亮度生成色階。

就如同人類科技發(fā)展史一樣，人們總是在發(fā)現(xiàn)問題解決問題和改進方案。如下圖所示，這種符合人類認知習慣的色彩空間搭配出來的顏色，其數(shù)值亮度并不是與人眼感知亮度相通的，這注定需要人為介入來改變局面。

以至于依靠這種方法生成的色彩階梯肉眼可見的過渡不均勻，且同階梯不同顏色間差異過大。

于是乎，這里調一下亮度，那里調一下飽和度，經(jīng)過不懈的努力花費了巨大的成本終于得到了滿意的效果，然后發(fā)現(xiàn)整個色板參數(shù)完全失控了。

推導經(jīng)驗無法復用，色板升級只能肉眼調，主題定制純靠研發(fā)批量替換......

至此，人們發(fā)現(xiàn)，傳統(tǒng)的色彩空間配色方案弊端主要體現(xiàn)在無法科學準確的表達顏色亮度上，也終于意識到，計算機對顏色的識別和處理是線性和對稱的，而人眼對色彩的感知是非線性和不均勻的。

簡單的例子就是紅色比藍色亮（刺眼），綠色比紅色亮（刺眼）。

所以，這些基于 RGB 色彩空間擴展出來的配色工具或空間（HSB、HSL 等）終究是要被取代的，這也正式促使了 感知均勻色彩空間 的誕生。

由 CIE 組織（國際照明委員會）于 1976 年提出，理論上可以覆蓋人眼所能識別的所有色彩，其顏色總量遠大于傳統(tǒng)色彩空間，最大的特性就是數(shù)值變化均勻則顏色變化均勻，亮度亦如此，人們終于可以客觀的依據(jù)數(shù)值來判定顏色了。雖并非完全意義上的感知均勻，但相比傳統(tǒng)色彩空間已是質的飛躍。

完整介紹可參考《基礎概念》篇，這里不做贅述。

4. 為何選取感知均勻的色彩空間？

很多可視化產品都在推薦使用人眼感知均勻的色彩空間來搭建可視化色彩系統(tǒng)，不斷強調感知亮度均勻，但并沒有告訴大家為什么。

首先，這里需要強調的是，我們所追求的感知亮度均勻更貼切的說法應該是追求亮度的準確表達。

表達是否準確就像建房子一樣，磚是墻的基礎，墻美不美觀穩(wěn)不穩(wěn)定，取決于每一塊磚的大小是否標準，而衡量這個標準的前提是磚的長寬高都是可被衡量的。與之對應的，色板是否"美觀與穩(wěn)定"，取決于每一個顏色是否標準，而衡量這個標準的前提是顏色的每個指標都是可被衡量的。

圖片源自網(wǎng)絡，侵權請聯(lián)系

基于這個前提，我們就可以順利地構建出一個可被衡量且變化均勻的全量色板。

其次，區(qū)別于設計系統(tǒng)的是，可視化場景需要基于全量色板按照特定的規(guī)則擴展出不同類型的色板，如分類色板、發(fā)散色板等，而亮度又是這些特定規(guī)則中的重要指標。

因此，一個可被衡量且感知變化均勻的全量色板何嘗不是可視化設計的最佳選擇呢？

再其次，我們反向思考一下，如果將感知不均勻的色彩空間應用在可視化場景里會發(fā)生什么呢？

下面是一個描述美國各地雨水蒸發(fā)量的案例，可以非常明顯的觀察到一條分界線將整張地圖一分為二，這很容易讓人在解讀數(shù)據(jù)時發(fā)生誤判---分界線兩側數(shù)值發(fā)生了巨大的變化。

作者：Robert Kosara，查看 原文。

而通過觀察其圖例上的數(shù)值后發(fā)現(xiàn)并非如此，分界線兩側的顏色所代表的數(shù)值區(qū)間差均為 0.09，與其他顏色并無差異。

這正是由于分界線兩側的顏色感知亮度有較大差異，以及不同色調之間過渡不均勻所導致的。

通過這個案例我們可以看出來，很多對數(shù)據(jù)精度要求高的場景（如氣象預測），在分析數(shù)據(jù)時，需要遵循一個很重要的原則就是保證顏色的客觀性，降低顏色對數(shù)據(jù)分析結果的影響，降低解讀數(shù)據(jù)時數(shù)值變化量誤差（對應色彩變化量）。

最后，總結一下，使用感知均勻的色彩空間可以讓我們收獲什么？

它可以讓設計師真正擁有明辨色彩是非的能力。在看似復雜的全量色板上客觀、有依據(jù)的挑選合適的顏色（通過數(shù)值判斷顏色是否合適而非階梯判斷），用以表達明暗、冷暖關系（如發(fā)散色板的構建），構建貼近工程化理念的配色方案（如動態(tài)順序色板的構建）等。

5. 如何選取感知均勻的色彩空間？

在眾多感知均勻的色彩空間中，選取適合我們的色彩空間需要滿足以下幾個基本條件：

1. 易于操作，最好是有成熟的工具或算法可以用來深入了解對比；
2. 顏色變量易于理解，最好能夠像 HSL 等空間一樣符合人類認知；
3. 可生成自定義數(shù)量的階梯，且每個階梯的亮度可以自由把控。

① CIE 系列

基于這些基本條件，我們首先排除了 CIELab（CIELUV 與之類似），其色彩空間由 L（感知亮度）、a（紅綠通道）、b（藍黃通道） 三個變量構成。L 變量是相對可控的，但 a、b 變量不符合人類的認知，類似于 RGB 調色板一樣，不同的顏色是通過改變 a、b 變量中的紅綠與藍黃的量而得出的。

但也不排除使用該色彩空間配色的可能，觀賞一下。

而 CIELch 是 CIELab 的極坐標轉換，通過易于理解的 L（感知亮度）、C（色度，可簡單理解為飽和度）、H（色相）三個變量來形容顏色。同時，生態(tài)也比較完善，有多種工具可以不同程度的幫助我們生成色階，作為保留方案。

② OK 系列

OKLab、OKLch 針對 CIE 系列空間做了進一步優(yōu)化，糾正了色相偏移（阿布尼效應）與色度對感知亮度的影響（亥姆霍茲-科爾勞施效應）。

但這類色彩空間目前還處于早期階段，生態(tài)不完善，兼容的場景也很少，僅有的工具也只能作為調色器（如這個工具 OKLch-Picker）使用。此外，在該色彩空間內，固定色相與色度的同時可覆蓋的亮度區(qū)間要小于 CIE 系列色彩空間，超出限定區(qū)間的顏色又無法在 sRGB 色域內甚至任何設備上正常顯示，用于生成色階非常局限。所以，放棄之。

無論使用任何色彩空間進行調色，我們最終都要保證所有顏色均能在 sRGB 色域內正常顯示，這是底線。比如你使用了 P3 色域中的顏色，則會有部分用戶的設備無法顯示并自動取 sRGB 色域中相似的顏色來呈現(xiàn)，從而影響你的設計交付效果。

③ HCT

HCT 色彩空間是谷歌在 Material Design 3.0 中推出的新方案，基于 CAM16 色彩空間與 CIELab 色彩空間進行了優(yōu)化，通過 H（色相）、C（色度）、T（光度，源自 CIELab 中的 L） 三個變量描述顏色。

官方提供了在線配色工具，但使用該工具生成的黃色顯臟，可用色階少，且無法自定義色階，許多顏色在色階兩端有丟色偏色的現(xiàn)象。

但好在開源，我們可以借助其算法通過在代碼中自定義 T 的數(shù)量及數(shù)值模擬我們想要的效果。單看生成的色階效果其實還不錯，也能夠滿足基本的使用需求。

代碼源自：Jony，查看 原文。

import { argbFromHex, TonalPalette } from "@material/material-color-utilities";

// 定義 tone 梯度
const TONE_ARR = [0, 5, 10, 20, 30, 40, 50, 60, 70, 80, 90, 94, 97, 100];

const createTonalPalette = (hex) => {
// 將 hex 格式顏色轉化為 argb 格式
const argb = argbFromHex(hex);

// 創(chuàng)建 palette
const palette = TonalPalette.fromInt(argb);

// 在 palette 上取一組 tone 梯度對應的顏色數(shù)組
const colorArr = TONE_ARR.map((t) => hexFromArgb(palette.tone(t)));

return colorArr;
};

其感知亮度變化也是相對均勻的（PS 灰度模式效果）。

大家可能在很多教程里都看到過使用灰度模式（用詞精確，非黑白模式）來模擬感知亮度變化。首先需要申明的是：在 PS 里，有一個圖層疊加模式叫"明度"，在 Figma 里叫 Luminosity，總之使用這種方式來模擬的效果都是不準確的，推薦使用 PS 中的灰度模式來模擬，或者直接打印出來查看效果。

那為何使用灰度模式來模擬呢？（這個問題并未找到科學靠譜的答案，屬于猜測）

相信大家在初次接觸美術時都學過素描，通過簡單的黑白灰來表達一個物體的光影、層次關系，而色彩會有很明顯的情緒傳達。所以，要想表達人眼對色彩亮度的感覺，是不是去掉"色彩"會相對客觀一些呢？

基于該結論，我們還會發(fā)現(xiàn)這種方式除了可以用來模擬感知亮度變化以外，還可以用來體現(xiàn)明暗關系（如視障用戶無法順利通過顏色辨別圖形時可以依靠明暗對比來辨別），以及用來還原打印效果（打印數(shù)據(jù)圖表分析數(shù)據(jù)）等。

但有一個非常讓人難受的缺陷：默認情況下 Key Color（或主題色）很可能會不存在于生成的色階中，這就意味著需要不斷去嘗試取 Key Color 相鄰的色值讓其存在于色階中，或者通過定義無限多的 T 數(shù)量及數(shù)值讓其顯露出來，這顯然不符合我們"易于操作"的要求，放棄之。

④ 結論

其他調研細節(jié)就不在這里啰嗦了，總之，我們最終選擇了 CIELch 色彩空間。

至此，需要鋪墊的內容也就告一段落了，接下來我們通過實戰(zhàn)來看一下如何推導一套可視化色彩體系。

二、全量色板

推導整個色彩體系之前，我們已知的條件就是一個主題色。基于青云 QingCloud 品牌 VI 中定義的主題色，我們將其進行一個簡單的色彩演變，降低飽和度的同時微調亮度使其更加適用于互聯(lián)網(wǎng)產品但不脫離我們中立沉穩(wěn)的品牌調性。

這里需要注意，在做色彩空間轉換時，盡量保證精確度，從而提升后期顏色推導的精確度。

1. 基礎 10 色

① 24 基色

基于 RGB 色彩空間，我們首先需要繪制一個標準色盤。

通過正色取值法，以正紅色為基準，間隔 15° 取色，中間會覆蓋正藍（210°）、正青（180°）等顏色，得到一個標準的 24 基色。當然，這些顏色并不能直接拿來使用。

與正色取值法對應的是主色取值法，以主題色色相為基準間隔 15° 取色，得到一個色相偏移的 24 基色。但經(jīng)過嘗試，我們發(fā)現(xiàn)，該方案由于主題色色相的不確定性（經(jīng)驗復用時會發(fā)生），很有可能導致取出來的顏色"不當不正"，做顏色矯正的成本較高。

② 8 基色

基于生成的 24 基色，我們選取人眼最容易識別且符合人類認知的 8 個基準色：紅、橙、黃、綠、青、藍、紫、粉。

這里取色的過程可以根據(jù)自己產品的調性對部分顏色特殊處理，如我們取的粉色就相對沉穩(wěn)一些。

③ 色相矯正

雖然現(xiàn)在生成了 8 個基準色，但仍然不能直接使用。此時，我們需要結合一些條件對色相進行偏移。

1. 首先是保證視覺舒適度，如黃色、青色過于刺眼；
2. 其次是基準色之間要肉眼可區(qū)分；
3. 最后是生成的梯度色板之間也要肉眼可區(qū)分（如我們的主題色與綠、青基準色經(jīng)過感知均勻的色彩空間轉換后生成的梯度色板十分接近）。

以上矯正過程需要結合后續(xù)的推導結果不斷循環(huán)往復來回調整，直至符合要求。

④ 色彩矯正

前面我們花了很多篇幅介紹色彩空間，在這一步才真正得以體現(xiàn)。我們先將顏色轉換至感知均勻的色彩空間，方便后續(xù)對色彩進行處理。

轉換至感知均勻的色彩空間后，我們根據(jù)主題色的感知亮度將其他顏色也設為一致，這是體現(xiàn)整個可視化色彩體系貼近品牌調性的關鍵步驟，因為我們會拿這些基色去生成全量色板。

大家可能發(fā)現(xiàn)我們在這個過程中選用了 HCT 色彩空間進行轉換（不是打臉哦），因其調色器工具能自動根據(jù)感知亮度調整色度致使各個顏色都保持和諧。當然，你也可以使用其他感知均勻的色彩空間來做轉換，差異不大。

此外，大家可能還會有疑問，黃色和橙色怎么像?一樣？為什么還放在這里？因為在真實使用場景中，色板里的顏色并不一定都能被使用到，這是其一。其二，顏色長的丑并不能否定它作為我們生成色階的基準色。（后面的推導流程推翻了這個結論，但仍不能否定它存在于色板中）

三步變化效果。

⑤ 生成中性基色

常用的中性色大家都知道有中性中性色和冷調中性色，結合品牌調性我們選用了冷調中性色?；谒{色我們可以通過降低色度的方式擴展出中性基色。

這里的中性色比較特殊，僅適用于圖表圖形中用以中和色調，而非用于文字、填充、軸線等場景的全局中性色。

⑥ 相對亮度驗證

通過上面的步驟，我們得到了感知均勻的 10 個基色，我們使用 Chroma.js 中的相對亮度計算工具驗證一下，方便我們基于這些基準色擴展色階。

這里引入了新的概念"相對亮度"，可以查看 W3C 相對亮度 的計算公式和 維基百科 對其的定義。大概可以理解為感知亮度的另一種表達，任意兩個顏色的相對亮度值一致說明其感知亮度（HCT 中的 T 或 CIELab 中的 L）值也是一致的。白色為 1，黑色為 0。

當然這里我們其實是無需驗證的，因為在色彩矯正步驟 2.1.4 里已經(jīng)基于 HCT 色彩空間將 T 設為一致了，那其相對亮度值也是一致的。我們驗證的目的是為了配合后文會提到的 Chroma.js 工具及相對亮度等差數(shù)列生成色階。

2. 完整色階

首先需要判斷一下需要多少個階梯，通常情況下的階梯有 7、9、11、13 幾種，大家根據(jù)自己的需要選擇。我們選擇了 13 階梯，一方面可以使色階過渡細膩一些，另一方面也可以讓取色范圍更廣一些。

其次，談起色階就不得不說一下插值。插值的目的是為了獲取一個有規(guī)律的亮度變化曲線，使色階過渡均勻。通常的做法就是固定首尾兩個點，通過一些算法或工具生成對應的貝塞爾曲線，也可以使用簡單的等差數(shù)列來完成。

而感知均勻的色彩空間有一個很大的特征就是：它的色彩空間是三維且不規(guī)則的，固定 L、C、H 三個變量并從中"切一片"下來放進二維平面中觀察，你會發(fā)現(xiàn)它的形狀是不規(guī)則的。固定其中任意兩個變量改變第三個變量時，都會影響這個二維平面的形狀，三者互相影響。

這里有點兒考驗大家的立體幾何想象能力。

這就意味著，不管你的亮度曲線是等差數(shù)列還是各種高大上的貝塞爾曲線，當你把曲線套進色彩空間中 360° 旋轉切換色相生成色階時，曲線中的某些點說不定會跑出整個三維色彩空間。這就需要聯(lián)動色度及色相一起做各種矯正工作，對設計師來說學習成本和操作成本是巨大的。

我們想簡化整個流程。前面我們定義好了 10 個基色，也得知其相對亮度值均為 0.287 左右，這就相當于定義好了整個色階中的"中間"階梯，我們按等差數(shù)列向上向下分別取不同數(shù)量的階梯即可，之后借助現(xiàn)成的算法或工具幫助我們去做矯正工作。

為什么基準色階往右的階梯要多一些？

主要原因在于基準色階的相對亮度較低，自然可以往亮處擴展的多一些。那為什么我們不在這個基礎上間隔取樣，使左右兩側的色階數(shù)量相等看起來對稱舒服一些呢？

這是由于我們在擴展分類色板、順序色板等時發(fā)現(xiàn)，經(jīng)常需要按不同規(guī)律來間隔取樣，這樣劃分會使我們的可選擇余地多一些，不至于陷入亮色不夠用，暗色又用不到的尷尬境地。

通過調研了十幾個工具后發(fā)現(xiàn) Chroma.js 正好滿足我們的需要。我們只需要選擇合適的色彩空間，定義好 Key Color（基準色），定義好相對亮度等差數(shù)列即可順利生成色階。

受 @少年游 的 文章 啟發(fā)，這里插播一個知識點：韋伯-費希納定律，可以解釋我們?yōu)槭裁磿褂玫炔顢?shù)列來設計色階。

定律現(xiàn)象：人眼對亮色區(qū)域的顏色變化敏感度要高于暗色區(qū)域。

按照傳統(tǒng)的 HSL 色彩空間生成色階時，需要在亮色區(qū)域將階梯層級設計的細膩一些，也就是亮度變化度（非 L 值的直觀體現(xiàn)，需要計算）要小于暗色區(qū)域，防止使用亮色區(qū)域相鄰色階時造成亮度變化過大的錯覺。如圖左，淺色按鈕之間的變化度為 2.6 倍，而暗色按鈕之間的變化度為 1.1 倍。

而我們使用的感知均勻色彩空間就很好的避免了這個問題，只要保證顏色之間相對亮度值的變化量是一樣的（等差），那就說明無論是淺色按鈕還是暗色按鈕他們之間的變化度也是一樣的，如圖右。

① 基礎色階

基于 Chroma.js，我們生成了大部分顏色的色階。

② 特殊色階

而當我們按照同樣的規(guī)則去生成黃色與橙色色階時，我們發(fā)現(xiàn)整個色階過于偏"暗"導致可用階梯非常少。

于是，經(jīng)過不斷地嘗試后發(fā)現(xiàn)：通過提升黃色與橙色的基準色感知亮度與色度則可以提升整個色階的亮度與色度，并保持變化均勻。因此，針對黃色與橙色，我們選擇基準色色彩矯正前的顏色（2.1.3 步驟中所得出的顏色）做為新的基準色生成色階。

這個過程由于色彩空間、算法等缺陷會導致部分顏色產生差異，但屬于肉眼無法辨別的差異，還可接受。

③ 色彩矯正

現(xiàn)在，我們擁有一套完整的色板了。但仔細觀察后發(fā)現(xiàn)，個別顏色有些不太符合我們的品牌調性，感知亮度或色度有些過了。

我們手動壓一壓，微調得到最終的全量色板。（綠色因與主題色過于接近，去之）

這些微調其實屬于可以不調的程度，并不會在實際生產過程中影響自動化交付效果。

3. 色彩驗證

生成全量色板后不意味著推導工作可以結束了，好的色板是要能經(jīng)得住考驗的，同時也是循環(huán)往復來回調整基色的必要過程。

① 相對亮度

驗證全量色板中的每層階梯顏色是否符合相對亮度標準，這也是檢驗色階是否過渡均勻的重要手段。

灰度模擬效果還不錯，使用 PS 中的灰度模式模擬。

亮度曲線分布一致，使用工具 Huetone 模擬。

② 色差驗證

在感知均勻的色彩空間內，驗證任意兩個基準色之間的色差，其目的是為了保障視力正常的用戶能夠順利分辨出兩個顏色的不同。我們基于 CIE2000 標準進行驗證，Delta E ≥

18 即滿足，可用工具 Color Contrast 進行計算。

"18"這個值的說服力有待考證，暫以其為標準。

CIE2000 較 CIE1976（目前使用范圍較廣） 在算法上進行了優(yōu)化，描述色差更加準確。

可以發(fā)現(xiàn)，部分顏色間的色差是不滿足標準的（紅字加粗部分）。

首先我們這里校驗的基準色都是可以直接拿來用在設計稿中或者用于后期推導其他色板的，所以校驗目標顏色的亮度階梯是固定的，如黃色取亮度 0.6 階梯，橙色取 0.44 階梯。

所以，留給我們的選擇就是改變色相與色度，通過微調的方式重新生成色板，使被校驗的基準色達到色差要求。

經(jīng)過多次嘗試，我們發(fā)現(xiàn)：如橙色，滿足色差要求的同時整個色階會偏向紅色；而黃色，滿足色差要求的同時整合色階需要偏向綠色，結果會很臟，否則會更加偏向橙色不滿足要求。

最主要的原因是：感知均勻的色彩空間并不像傳統(tǒng)色彩空間那樣可以肆無忌憚的調出想要的顏色，加上工具和算法的限制會導致微調并不起作用，直觀的體現(xiàn)就是換了其他相近的顏色但生成的色階結果還是一樣的。

這個時候我們就需要做出取舍了，我們最終選擇了保視覺效果而非色差，或許我們后續(xù)還有機會回頭重新看待這個缺陷。

無法滿足 CIE2000 標準的顏色，也盡量保證滿足 CIE1976 標準，推薦使用工具 iWantHue 計算。

③ 色度分布

觀察所有顏色的色度分布趨勢，我們會發(fā)現(xiàn)用來生成色階的基準色剛好處于色度曲線頂點位置處，這是為何？

猜測：根據(jù)色度分布曲線我們可以大致推測出 Chroma.js 算法的關鍵點在于基準色，你輸入的基準色的色度會是最高的，然后依次向兩側色階降低。

那么，基于該結論，我們就可以知道為什么在步驟 2.2.2 中生成的黃、橙色階是不理想的了。因為你把整個色階里的最高色度點定的太低了，以至于使整個色階偏"暗"。這也反向驗證了我們選擇色彩矯正前的黃、橙色作為新基準色的做法是可行的。

說通俗一點兒就是：選擇用于生成色階的基準色，一定要視覺舒適，要"漂亮"。舉個不太恰當?shù)睦?，如果你的基準色可以直接拿來用在設計稿中，那么它大概率就是一個合格的基準色。

最后，我們來對比一下我們的可視化色板（CIELch）與設計系統(tǒng)色板（HSB）的色階過渡效果。

灰度模擬效果。

三、分類色板

用于表示可視化場景中的不同類型的數(shù)據(jù)。

1. 競品分析

我們參考知名可視化產品 ColorBrewer2 中的分類色板，通過分析其不同主題中的色彩規(guī)則來制定我們的分類色板。

1. 主題一：三套不同亮度的色板，最多 8 種顏色，色相一致，適用于不同場景，同時也適用于不同品牌調性，如清新、沉穩(wěn)、復古，思路值得借鑒；
2. 主題二：兩套不同亮度的色板，最多 9 種顏色，與主題一原理類似，后續(xù)擴展主題時可借鑒；
3. 主題三：相鄰顏色色相一致但相對亮度明暗交替，最多 12 種顏色，適用于多數(shù)據(jù)類型的場景，可以借鑒；
4. 主題四：沒搞懂原理及用途，先放之；
5. 主題五：整體偏亮，最多 12 種顏色，相鄰顏色色相不一致但相對亮度明暗交替，所以也適合多數(shù)據(jù)類型場景，思路可借鑒。

結合其他可視化產品，我們確定了接下來要做的事情的一些基本思路：

1. 通過某種取色規(guī)則制定不同風格的分類色板，根據(jù)其效果選擇一套適合我們品牌調性的；
2. 分類色板要兼容多數(shù)據(jù)類型和少數(shù)據(jù)類型；
3. 少數(shù)據(jù)類型時，相鄰顏色色相不同且明暗交替；
4. 多數(shù)據(jù)類型時，相鄰顏色色相相同且明暗交替。

2. 生成色板

① 風格確定與基礎色板

分類色板顏色主要考慮明暗交替變化（兼顧視障用戶群體），其次考慮色彩美觀度及顏色間的對比是否協(xié)調，如黃、橙色不臟，中性色不能太深或太淺等。我們一步步來，先把風格確定一下。

在全量色板上，我們以主題色所在的相對亮度階梯為基準，通過明暗交替的方式排布取色標準點。

在進行明暗交替取色時，取更暗還是更明，主要取決于色彩美觀度及顏色之間協(xié)調性。

再以相同的規(guī)則，將取色標準點整體向上向下偏移取出相對較亮和較暗兩種風格的色板。

當然，如果你想要更亮或者更暗的風格，改變偏移量即可。

較亮。

較暗。

至此，我們得到了三套不同風格的基礎分類色板，結合我們的產品調性，并在實際使用場景中進行驗證，我們選擇了相對沉穩(wěn)、中立的版本。

灰度模式模擬效果。

色相相對亮度分布示意。

② 擴展色板

前面提到過，分類色板還需要兼容多數(shù)據(jù)類型場景。如我們現(xiàn)在的基礎色板中有 9 種不同的顏色，如果一張圖表需要用到 10 種顏色該如何解決？

常用的解決方案是將生成的基礎色板顏色循環(huán)使用，如 Echarts，但這種方案有一個很大的弊端就是會出現(xiàn)首尾顏色相接無法正常區(qū)分的情況。

因此，我們決定基于基礎色板按相鄰顏色色相相同但明暗交替的規(guī)則衍生出一套擴展色板。

注意觀察，基礎色板中的藍、紅、青、粉色相對亮度值為 0.36，而擴展色板中卻為 0.287。這是由于基礎色板顏色需要滿足明暗交替原則，而對應到擴展色板中時，相鄰顏色已為明暗交替的同色相顏色，因此無需再將所有暗色都處理成明暗交替。

擴展色板使用效果。

③ 關于使用順序

在風格確定步驟中，大家可能會有疑問：取色標準點怎么排布看懂了，但要得出分類色板，還差一個必要條件，那就是不同色階的擺放順序。

其實這個擺放順序就是分類色板中的顏色使用順序，這個順序至關重要，為何？

首先，無需過多解釋的就是：順序不一樣，意味著分類色板不一樣，這是不同可視化產品之間差異化體現(xiàn)的重要途徑，也就是我們前面提過的 體現(xiàn)整個可視化色彩體系貼近品牌調性的另一關鍵步驟。

其次，基于分類色板的特性我們可以明確的一點就是：這個順序是固定的，不能隨意更改，否則會破壞整個產品的視覺和諧度。你不能說環(huán)形圖用順序 1，玫瑰圖用順序 2，或者這個頁面環(huán)形圖用順序 1，另一個頁面環(huán)形圖又用順序 2。

最后，這個順序會直接影響取色標準點的排布。順序的不同，意味著原本應該取的暗色卻變成了亮色，導致整個分類色板明暗變化產生差異。

看到這里大家可能會發(fā)現(xiàn)，這正是用來生成不同主題的好手段??！

至于如何決定這個順序，應該是仁者見仁智者見智并無對錯的，這里只闡述一下我們的確立依據(jù)：

第一位是主題色綠，其次為藍色。一方面考慮使用綠、藍等偏中性的顏色可以保證大多數(shù)圖表在頁面中不會突兀，另一方面也能夠兼容大多數(shù) B 端產品的色彩基調。

其次為避免頁面過于單調冷淡，所以加入暖色--黃色中和。

約定成俗的語義色就是紅、黃、藍、綠，所以考慮將紅色也加進來。不過紅、黃色相鄰的話會使色板變得過暖，可以在其中間加入偏暖的中性色-紫色來使其過渡均勻。

此時整個色板呈現(xiàn)冷-暖變化趨勢，緊接著需要回到冷趨勢，同樣為了避免發(fā)生冷暖突變，我們加入絕對中性色--灰色來中和，順位往下走就只剩青色可選了。

接著就是暖色橙色，而粉色是個輕佻曖昧的顏色，使用時稍有不慎就會輕易打破整個頁面的風格，所以放在最后，整個色板的順序就定下來了。

此外，除了考慮顏色自身冷暖屬性、語義屬性外，還需要考慮識別度、視覺歧義、視障等因素。如從識別度角度考慮會使橙、黃色不相鄰，綠、青色不相鄰；如從視障角度考慮會使紅、綠不相鄰，粉、青色不相鄰等。

最后，需要申明的觀點就是：

可視化場景僅靠顏色是解決不了所有問題的，這其中需要設計師有能力將復雜的視覺問題和交互問題進行簡化、合理化，如使用恰當?shù)膱D表，使用紋理圖形輔助識別，重組數(shù)據(jù)便于理解等。

圖片源自：Matplotlib。

3. 色彩驗證

① 視障驗證

視覺障礙用戶群體主要是色盲色弱用戶，根據(jù) Color Oracle 的統(tǒng)計，全世界人類中，綠色盲占比 5%，紅綠色盲占比 2.5%，藍黃色盲占比 0.5%。我們需要保證的就是盡可能讓這部分群體也能夠無障礙使用我們的產品，無障礙解讀數(shù)據(jù)。

② 色差驗證

步驟 2.3.2 中詳細介紹了色差的驗證方式以及驗證目的，這里不贅述。

4. 應用

不在實際業(yè)務場景中驗證顏色的行為個人認為就是在耍流氓。

① 使用規(guī)范

實際應用時發(fā)現(xiàn)，圖表類型眾多樣式差異巨大，統(tǒng)一使用全量分類色板中的 9 個顏色并不合適。

如折線圖，其圖形（線段）視覺占比非常小，通常是 1～2px 粗細的線段。使用全量分類色板時，部分顏色（如橙色與黃色，紅色與粉色，綠色與青色）雖能順利辨識，但長時間查看會產生視覺疲勞導致辨識困難。

此外，在 Dashboard 或 BI 等場景中，通常會遇到數(shù)據(jù)量大，圖表類型繁多，數(shù)據(jù)類型繁多的情況，此時的頁面視覺效果將是災難級的（使用 Echarts 主題定制工具模擬）。

因此，針對常規(guī)場景，遵循少即是多原則，我們去除了可能會無法辨識的顏色，將可用顏色數(shù)量限制為 6 個。特殊場景不做限制，如桑基圖。

超出 6 種數(shù)據(jù)類型時，使用分類色板擴展色板，共 18 個。

超出 18 種數(shù)據(jù)類型時，使用強調色板。

② 應用效果

這里使用屏幕截圖，所以效果會出現(xiàn)些許偏差。

四、順序色板

通過亮度變化均勻的一組顏色表示具有順序、梯度、頻率等關系的數(shù)據(jù)。

1. 固定色板

顧名思義，固定色板即色階數(shù)量有限的色板，用于數(shù)據(jù)階梯較少的場景?？苫趦蓚€準則確定順序色板：

1. 色階亮度層次拉開；
2. 色階使用順序明確。

因此，從全量色板中選取色階時需要注意，亮色區(qū)域間隔取色，保證數(shù)據(jù)階梯之間能夠清晰分辨。

基于此，確定我們的 7 階固定色板。

最亮階梯不滿足對比度要求，用于圖表中可能無法識別；最暗階梯無法順利辨別多個顏色之間的區(qū)別，也應避免使用。

而明確色階使用順序時，除要考慮遵循規(guī)律（方便開發(fā)實現(xiàn)）外，還要考慮頁面和諧。通常的做法是從最亮階梯開始往上取，當數(shù)據(jù)階梯比較少時，其效果其實并不是我們想要的。

因此，我們改變一下這個順序：從中間階梯（主題色所在的階梯）開始往下取，取完再依次往上取。

該方案僅供參考，目前尚未與研發(fā)同學達成共識驗證其可行性。

最終，我們得到一個包含使用順序的色板（從左往右依次對應數(shù)據(jù)階梯數(shù)量）。

應用效果（以主題色為例）。

2. 動態(tài)色板

動態(tài)色板主要應對數(shù)據(jù)階梯量大且不可預知的場景，因此需要借助算法根據(jù)數(shù)據(jù)分布階梯自動生成對應的色階。

設計師僅需提供最亮、中間及最暗的三個顏色即可。

因應用場景區(qū)別于固定色板的應用場景，所以動態(tài)色板會使用到全量色板中的最亮和最暗階梯。當然你也可以選擇使用與固定色板相對應的最亮、最暗階梯，本質上設計師提供的三個顏色都是可以自定義的。

應用效果（以主題色為例）。

五、強調色板

與分類色板相對應，當分類數(shù)據(jù)較多時，或需對比數(shù)據(jù)時，通常會使用強調色板強調數(shù)據(jù)，弱化無關數(shù)據(jù)。

1. 取色規(guī)則

基于全量色板，以基準色作為強調色，向下擴展對應的弱化顏色。

注意，與分類基礎色板不同的是，通常情況下的強調色不會同時出現(xiàn)，因此無需考慮明暗交替；其次，與分類擴展色板不同的是，因分類擴展色板需要考慮對比度，這里則需要盡量弱化，所以弱化色亮度要高于分類擴展色板。

2. 應用效果

六、發(fā)散色板

用來表示具有正負、高低、漲跌等關系的數(shù)據(jù)，擁有臨界中間值，因此通常使用一對冷暖色來呈現(xiàn)。

1. 取色規(guī)則

首先，根據(jù)發(fā)散色板表達數(shù)據(jù)對立關系的特性，我們在選取對立冷暖色時，可以通過模擬視障效果來排除掉一些可能會出現(xiàn)問題的顏色。

我們選取了既可以表達冷暖關系又不會出現(xiàn)問題的三組顏色，以及表達中立的一組顏色。

其次，由于發(fā)散色板的使用場景與順序色板類似，因此我們可以基于全量色板擴展出對應的固定色板。并使用 Chroma.js - chroma.mix 工具將對立相接的兩個顏色進行混合，使其過渡更加均勻。

視障用戶效果模擬，既不能混淆顏色，又不能改變原冷暖關系映射。

而為了應對數(shù)據(jù)階梯量大且不可預知的場景，我們可以基于固定色板擴展出動態(tài)色板，與順序色板動態(tài)色板原理類似，本質上是一組漸變色板，數(shù)據(jù)階梯分布區(qū)間有多少，則可以在漸變色板上插對應數(shù)量的值。

此處再次體現(xiàn)感知均勻色彩空間的優(yōu)勢，漸變色過渡也是非常自然的。

2. 應用效果

可視化效果使用 Datawrapper 模擬。

3. 色相偏移

關于發(fā)散色板的生成，其實還有一種使用范圍更廣的色相偏移色板，相對無色相偏移色板來說過渡更加自然，更加符合人類對色溫的認知。也就是常說的隨著色階的變化冷色會更冷，暖色會更暖。先來看下對比效果：

我們的方法是取三種不同暖色中的關鍵色與三組不同冷色中的關鍵色，使用 Chroma.js Color Palette Helper 進行混合，生成新的色相偏移色板。

但使用該方案并不能生成所有想要的色板，因為我們的一個大前提是所有顏色取至全量色板。如在生成紅-藍發(fā)散色板時發(fā)現(xiàn)，并沒有合適的三組暖色供我們選擇用來取出關鍵色，這就會導致生成的色板偏色嚴重無法使用。

所以，個人猜測，未來一方面應該向更科學合理的色相偏移方案探索，另一方面在該場景中不應將取色標準局限于全量色板。

由于我們的產品中很小概率會使用到發(fā)散色板，所以這里不做深入研究，也避免誤導大家，就此打住。

七、語義色板

可視化場景中不受主題、風格影響的顏色，是約定成俗具有特定寓意的顏色，通常用于表示告警等級、正負關系等。

1. 取色規(guī)則

關于語義色板的取色來源頗受爭議，一種方案是直接選取設計系統(tǒng)中的語義色，另一種是從可視化全量色板中選取并重新定義。其實兩種方案各有優(yōu)劣，關鍵在于如何客觀評判。我們選擇從可視化色板中選取并重新定義的理由如下：

1. 設計系統(tǒng)色板的色彩空間與可視化有本質區(qū)別，無法做到統(tǒng)一；
2. 設計系統(tǒng)中定義的語義色感官上飽和度及亮度與可視化色彩不統(tǒng)一，融入可視化場景中不和諧；
3. 圖表中的元素形狀面積通常占比較大，與其他顏色的元素搭配時，使用可視化色彩會更協(xié)調；
4. 設計系統(tǒng)中的語義色從使用場景、設計思路等角度考慮的話，會與可視化場景有細微差別，解耦設計更合理一些。

注意灰色語義色取至中性色板，后面會解釋原因。

2. 應用效果

八、中性色板

中性色板用于可視化圖表中的標題、軸線、文字等場景，與設計系統(tǒng)中性色板保持一致，這里不做特殊定制。上文提到過，為何中性色板區(qū)別于語義色板，可以與設計系統(tǒng)共用呢？

1. 首先中性色板本質上都是中性色，應該區(qū)別于"有色彩"的顏色。那么，從其使用場景上來看，中性色板可以不受系統(tǒng)限制，獨立于設計系統(tǒng)或者可視化組件庫以外，成為一套公共的色板；
2. 其次，從使用者角度來考慮，中性色板可以說是使用范圍最廣的，這就形成了肌肉記憶，不再適合重新開辟一套來給大家造成記憶負擔；
3. 再其次，從頁面效果來看，理想狀態(tài)還是所有中性色保持一致，不能說承載圖表的卡片標題是一個顏色，而同級別非圖表卡片標題又是另一個顏色；
4. 最后，從底層色彩空間來看，中性色是不受色彩空間限制的，可以通用于各種不同色彩空間搭建的系統(tǒng)中是必然的。

九、總結

總之就一句話，關于顏色的探索是永無止境的，隨著探索的不斷深入，越發(fā)覺得距離踏入門檻是越來越遠了。