Dembrandt Skills

它適合什麼工作，以及為什麼是它

當一個產品只有兩三個品牌色、其餘顏色都是臨時挑的時候就用它：沿用預設值的灰色邊框、和藍色不屬於同一家族的紅、某個人用眼睛挑出來的 hover 色。這個配色技能給的答案是：那些缺的顏色應該被「推導」出來，而不是被挑出來，並且為每一類顏色給出明確方法。

這套方法具體到可以檢查。互動狀態來自對基礎色相做明度位移；中性色是低飽和度的品牌色相，讓灰色不再看起來像外人；語意色沿用品牌的飽和度與明度，使錯誤、警告與成功具有相同的視覺重量。每一項都是可以拿實際配色去核對的規則，這正是它和「用一組好看的色階」的差別。

它還對兩件多數配色建議會跳過的事表態：純黑配純白是舒適度問題，而不是對比度的勝利；以及停用狀態應該是中性色，而不是淡化的品牌色，這樣停用的控制項才不會看起來只是「還沒被按」。這兩項都是明確主張、都寫成規則，也值得你刻意決定是否同意。

什麼情況不該用它

當顏色是品牌表達而不是系統時，它就不適合：品牌識別更新、行銷活動，或任何「配色必須先被感覺、再被推導」的場合。這套方法最佳化的是協調與無障礙，而協調的配色不一定有辨識度。

如果你已經有一套持續維護的變數，而且 hover 與 focus 步驟都有了，這個技能除了提供第二意見之外沒有幫助，還可能替你改名字。在專案中途採用一套推導方法，意味著要嘛搬移你的變數，要嘛同時跑兩套命名。

這個專案裡有兩個技能不是自足的：要從實際線上網站讀取真正的設計變數，需要作者另外提供的引擎。如果你要的是純設計知識，那沒問題，因為多數技能被描述為純知識，但除非你願意執行那個引擎，否則不要把規劃建立在擷取類技能上。

它需要什麼，以及會產出什麼

最低限度的輸入是一到兩個品牌色及其數值。這個配色技能裡的範例，就是拿一個品牌藍產出一整套變數：每個品牌色的數個狀態、由品牌色相推導出的七階中性色、錯誤／警告／成功／資訊等語意色（含它們的淡背景），以及 focus、選取、遮罩、骨架與陰影等功能性變數。

回傳的是以自訂屬性寫成的變數，加上各步驟的理由，以及一份標示清楚的檢視清單。清單其實是更有用的那一半：它會問 hover 與 active 是推導出來的還是挑出來的、灰色越亮時飽和度是否隨之下降、停用狀態是否為中性色，以及到底有沒有 focus 這個變數。

前置條件很少：這個配色技能本身不需要建置流程、不需要相依套件、也不需要任何服務。你唯一該準備的是拿來推導的那個顏色——要給實際數值，而不是描述——以及決定你的程式庫用哪種輸出格式，因為範例是為自訂屬性寫的，換成別的格式需要自行調整。

工具支援、權限與相依性

專案以概括方式說明自己的相容性，安裝路徑則透過一個讀取技能包的套件執行器。已發布紀錄把該專案的來源查核標為 verified。本導讀所讀的進入點檔案帶有檢索用的中介資料，用來告訴代理這個技能何時適用；這正是這個技能包所依賴的機制，而不是靠明確指令。

多數技能是純指示文字、沒有執行足跡，而這個配色技能就是其中之一：它只需要讀你的顏色、寫出變數值。至於範圍更大的權限問題屬於擷取那條路徑——那部分會和實際線上網站通訊，因此也會用到網路，而專案文件說明它需要透過代理的工具設定連接它自己的引擎。

有一項相依細節值得事先規劃：擷取類技能在文件上要求那個引擎的最低版本，而且連線是在代理層級設定，而不是在專案裡面。如果你啟用它，你打開的界線是「你的代理會去連你指名的任意網站」，所以在接上之前請刻意決定這是否可接受。

和「用眼睛挑色」相比

對一個小型個人專案來說，仔細挑六個顏色會比推導更快，甚至更好看，因為推導最佳化的是顏色之間的關係，而你想要的可能是刻意打破關係的某一色。這個技能的價值在於配色必須撐得住別人往上加東西的時候；那也正是「我挑的時候看起來沒問題」不再構成理由的時候。

和設計工具內建的配色產生器相比，差別在理由而不在結果。產生器給你一組色階；這個技能給你色階，加上每一步是為了什麼的明確說明，而這正是讓第二個人不必用猜的也能延伸配色的原因。如果永遠不會有別人碰這些顏色，那這份成本就真的沒有回報。

和直接採用一套知名公開設計系統相比，取捨正好相反：你繼承了別人想清楚的決定，但失去了自己的品牌。這套方法則是中間那個選項：以你的品牌色為種子，其餘推導出來。

如何自己驗收成果

推導出來的配色在色票條上看起來很有說服力，一用就出問題。請在實際使用的位置檢查。

• 量測實際成對的組合，而不是你以為的組合：內文對頁面底色、文字對每一個語意淡背景、focus 外框對它會出現的每一種表面，以及停用文字對它自己的底色。
• 把同一個畫面在淺色與深色各呈現一次，確認沒有東西變成看不見。從單一色相推導的配色，常會產生一種在另一個模式下會消失的淡背景。
• 把所有控制項切到停用，並用鍵盤逐一聚焦，確認這兩種狀態都還和一般狀態分得出來。這兩種狀態正是手工複製配色時最常被漏掉的。
• 確認對分不清紅與綠的人來說，各語意色彼此仍然可以區分。當色相無法承載意義時，重量與位置就要承擔。
• 把配色放在介面裡看，而不是放在色票清單裡，而且要在它會被使用的最小與最大尺寸下看。一個在 1px 時看來是一條線的邊框色，在較大圓角下可能看起來是一塊色塊。
• 把結果對照技能附的檢視清單，確認每一行你都能答「是」。那份清單是專案自己的標準，也是找出被跳過步驟最省力的方式。

來源、版本，以及實際讀過的範圍

上面這些判斷是針對本頁顯示的那個提交寫成。若已發布紀錄移到另一個提交，這份導讀會停止顯示，而不是繼續描述沒有人重新讀過的版本。

實際讀過的是：專案的儲存庫總覽（內含完整技能清單，以及安裝與引擎說明），以及其中一個技能的完整內容——該提交下的演算法配色技能。其餘技能只在總覽裡看到一行描述，所以上面任何內容都不是對它們的評價。沒有安裝任何東西、沒有執行引擎、沒有讀取任何網站，也沒有產生任何配色或做過對比測試。關於方法會產出什麼的敘述，來自該技能自己文件上的輸出；上面建議的檢查項目是本導讀提出的，不是該專案實測的結果。