本章會從實操出發，結合真實項目為大家帶來配色實踐。期間會介紹項目選色邏輯、配色過程、使用到的工具及如何建立色彩系統。

往期回顧：

項目背景

21 年我司進行業務調整，原保險業務從當前產品中獨立出去，作為一家全新平臺為印尼用戶提供保險選購及理賠服務，為此我們提供了新的產品設計和配色。

一、定義主色

1. 選擇色相

根據上一章提到的選色邏輯，我們依次從產品情緒、行業屬性和目標用戶幾個緯度去思考。作為一家全新的保險平臺，我們希望產品給到用戶專業、安全、信任之感，那么藍色、綠色可以作為備選，藍色代表專業、權威，綠色代表安全、健康。后續我們做了相關行業調研，發現大部分本地產品也使用了這兩個顏色，可以確保備選顏色是符合行業喜好的，屬于安全的用色范圍。最后考慮到用戶的地域屬性，印尼大部分用戶都信奉伊斯蘭教，對綠色有著非同一般的熱愛。結合本次項目訴求，便選擇了綠色成為我們產品主色。

2. 確定色調

明確了主色色相，但同一色相會有冷暖、深淺之別，給到用戶的心里感受也略有差異。具體到本次項目中，暖綠有溫暖、活潑、歡快的感覺，冷綠則帶給用戶冷靜、平和的情緒。對于本次項目，冷綠更加符合產品定位。

3. 調整飽和度、明度

飽和度控制色彩的艷麗程度，明度控制色彩的明暗變化，這兩項參數直接影響色彩的最終效果，所以需要同步交替調整，直到選出最合適的。考慮到主色常用于按鈕或重要文本，所以需要注意色彩的對比度，確保文本在界面中的可讀性。在本次項目中，“綠色”本身屬于對比度較小的顏色，為了獲得合適的對比度，需要調整更大的飽和度和更低的明度。經調整之后，我們測試了色彩的對比度為 3:1，滿足 W3C 中給到的色彩對比度建議。

二、推導輔助色

1. 匹配色相

根據輔助色定義，我們匹配到了不同色相的輔助色，但并不是所有顏色都是我們需要的，需要根據經驗做出一定刪減。如同類色中的兩個綠色，色相上與主色過于接近，使用過程中會造成視覺混淆，所以我們剔除這組顏色。再如中差色與對比色中都有黃色，為了與橙色區分更加明顯，我們刪除對比色中的黃色。經過一系列刪減后，留下來的便是我們需要的色彩。此時也可以對色相進一步調整，如類似色中的藍色偏向湖藍，為了盡量和主色拉開差別，我們選擇色相向右偏移。

2. 視覺感官校準

以上色彩只確定了色相，沒有進行飽和度、明度調整，視覺上并不屬于同一層級。為了獲取更加統一的配色，需要對其進行調整，這一過程被稱為視覺感官校準。如何校準？有人通過給色彩疊加黑色，對比色彩亮度進行校準。但不同顏色本身亮度不同，強行調整一致會導致部分顏色失衡。所以此種方法可作為參考，但不具備太大可靠性，實際工作中還需依靠自身經驗進行調整，確保視覺上和諧統一。以下為完成校準后的配色。

三、推導中性色

第二章提到中性色可通過調整明度或透明度得到，本項目使用場景比較固定，所以決定調整明度來得到中性色。考慮到主色為“冷綠”，與偏藍的中性色搭配可保證色彩調性一致，于是我們取藍色色相值，調整飽合度獲得最終色彩。需要注意的是隨中性色明度依次降低，飽和度需要逐級增加。最后確保主要用色符合無障礙設計指南，我們對一級、二級、三級文字用色進行了對比度測試，符合無障礙設計要求。

四、生成梯度色板

梯度色板可以提供更多配色，覆蓋更多使用場景，避免后續新增顏色的煩惱。早期為了獲得梯度色板需要設計師利用公式計算，現在可以直接使用在線工具生成。如 Ant design 的色板生成工具（ https://ant.design/docs/spec/colors ），Material design 的色板生成工具（ https://materialpalettes.com/ ），Eva Design System 的色版生成工具（ https://colors.eva.design/ ）。由于不同平臺算法不同，生成的色版效果也存在差異，這里首推 Ant design，對比其他平臺色相變化更豐富、顏色更均勻、色階也更明確。

五、建立色彩系統

1. 如何理解色彩系統？

色彩系統隸屬設計系統的一部分，是對色彩進行科學管理的體系。不同于色彩規范主要針對設計側，而是需要打通開發聚焦產品代碼中。

2. 色彩系統包含什么？

簡單來說色彩系統由 design token、色彩庫和說明文檔構成。design token 是設計與開發約定一致的色彩名稱，作為色彩調用的唯一憑證。色彩庫是包含 design token 和顏色參數的樣式集合，供我們在設計和開發中調用。說明文檔類似于設計規范，定義了色彩的使用方式，為我們的使用提供指導。

3. 如何建立色彩系統

①token 命名

如何命名需要考慮 token 層級和 token 構成。

關于 token 層級，設計師 Lukas Oppermann 在文章《Naming design tokens》(https://medium.com/user-experience-design-1/naming-design-tokens-9454818ed7cb)中有提到一般設計系統會將 token 分為三個層級，核心 token（core token）、語義 token（semantic tokens）和組件 token（component tokens）。核心 token 存儲的是原始值作為構建設計系統的基礎，語義 token 引用核心 token，它的名稱描述了 token 的預期用途。組件 token 引用語義 token，并將 token 綁定到對應的組件。較多的層級可以使 token 命名更加清晰，但層層嵌套的邏輯也增加了管理的難度，Lukas Oppermann 在文中提到也可以使用一層或兩層。

關于 token 構成，體驗設計師 Nathan Curtis 在《Naming Tokens in Design Systems》(https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676）一文中指出為了更加充分的描述 token，token 可以由名稱空間（namespace）、目標對象（object）、基礎樣式（ base）、修飾符（Modifier）構成。名稱空間對應系統、主題名稱，目標對象對應組件、組件元素和復合組件，基礎樣式是 token 的主干部份，包含樣式、屬性、語義，修飾符表明狀態、尺度、模式等。由于篇幅原因，此處只是簡單介紹，感興趣的同學可以點擊原文查看。

按照兩位作者的觀點，筆者對本次色彩系統進行了 design token 命名，如下所示：

②建立樣式庫

樣式庫是設計與開發調用的基礎，需要在設計工具中實現 token 的層級邏輯，同時方便開發同學查看。筆者主要使用的工具是 figma，Figma 為我們提供了豐富的功能和插件建立樣式庫，以下會介紹些主流方式及優缺點，大家按照項目實際情況選擇使用即可。

local style：figma 支持將色彩定義為全局樣式，并對樣式進行命名。設計在調用樣式后，開發便可以在查看面板看到對應 token，基本實現了樣式庫的作用。但 local style 不支持 token 的層級嵌套，只能實現單層級 token。如果你的項目剛好使用了單層級 token，那么建議你使用此功能。

local variables：在今年 6 月份的 config 大會中，figma 發布了變量功能，雖然 CEO Dylan Field 先生說不會推出 design tokens，但變量功能卻完美實現了 token 的作用。它支持將色彩定義為變量，且可以實現層級嵌套，開發在查看面板也可以方便的看到變量名稱，算是解決了 figma 在 design token 方面的缺陷。

Figma token：一款定義 design token 的插件，且支持 token 的層級嵌套。開發查看 token 名稱目前有兩種方式：1.可在 Figma token 的 inspect 面板進行查看，但插件需要在編輯模式下使用，意味著你需要給到開發編輯權限，這無疑會增加團隊成本。2.插件支持將 token 轉化為 figma 樣式和變量，并保持當前的 token 名稱，此時開發可以在 figma 的 inspect 面板查看 token，建議使用此種方式，經濟實惠。

③輸出說明文檔及團隊推進

一般文檔內容包含使用規則、注意事項、場景描述、token 名稱、色值參數等等，也可根據實際情況作以增減。輸出說明文檔后，整個色彩系統搭建完成，接下來需要推進團隊使用。為確保整個系統在項目中順利落地，最好組織相關人員進行一次宣講，介紹清楚使用規范及注意事項，明確要求嚴格按照系統執行。