品牌重塑後，把四個元件庫各自發展的色彩，收斂為一套共通的語意系統

專案概述

公司創立 30 週年，迎來了首次的品牌識別重塑。作為數位產品端的 Design Lead，我的首要任務是帶領團隊，將公司旗下的數位產品 GLOBIS 学び放題與新的品牌識別對齊。

本次重塑在數位產品端聚焦於「品牌色彩」的翻新（字型與元件尺寸仍遵循各 OS 原生規範）。品牌團隊交付給產品端的，只有 Primary 的藍與 Secondary 的橘這兩個品牌色。然而，對橫跨四個平台的產品而言，兩個顏色並不足以應付複雜系統中的所有 UI 元件。因此，如何從這兩個顏色衍生出一套各平台都能使用的色彩系統，是本次專案的起點，也成為我們重新審視現存設計系統的契機。

本次重構涵蓋產品生態系中的四個平台元件庫（學習者端的 Web／iOS／Android，以及企業人資管理端的 Web）。兩端的重構過程幾乎相同，因此本文以學習者端為主要說明對象。

定義專案目標與範疇

Step 01 現況整理與專案可行性評估

在接收到品牌團隊的需求後，我帶領設計師們對這四個元件庫進行了現況整理，並對元件庫內定義的色彩進行盤點。在這個過程中，我們發現在專案執行前，有幾個必須先解決的「設計負債」：

1. 色彩定義缺乏單一真實來源
   四個元件庫各自獨立，品牌色分散於各處。長期迭代下，色彩定義已出現分歧。例如：即便同樣是 Primary／Secondary 色系，各元件庫中的色碼與色階數量（3～5 個不等）皆存在差異。
2. 色彩定義缺乏語意與使用規範
   系統內並無定義色彩的配比或使用邏輯。這導致跨平台的設計極度仰賴設計師之間密集的溝通來維持視覺一致性，且無可避免地在細節處產生用色差異。
3. 色彩定義缺乏統一命名方式
   色彩系統並非一開始就經過縝密設計，而是經由不同設計師之手逐步擴張；各平台的色彩命名彼此獨立，也與工程端的命名無關。這導致設計師在執行跨平台設計時，需要頻繁進行情境切換，不僅容易出錯，更徒增了心力的耗損。

Step 02 範疇擴張之交涉：從「色彩替換」到「系統重構」

在完成現況盤點後，設計師們意識到若安於現況、僅在各個獨立系統上進行表面的「色彩替換」，不僅難以整合視覺不連貫的問題，且當未來再次面臨品牌重塑時，我們仍將付出高昂的勞力與時間成本。

為此，我向各開發團隊的 PO 與 Scrum Master 展開交涉。我以短期的系統投資，能換取未來跨平台維護的效率為切入點，運用公司既有的兼職制度（成員最多可將 20% 的工作時間投入其他團隊或部門的專案），為各團隊的設計師爭取到投入色彩系統重構的產能。

在品牌團隊與我接洽的當季，設計師們其實已開始投入初期的討論與規劃；專案正式取得組織的認可與產能，是在下一個季度。

Step 03 確立雙軌目標與「不做什麼」的範疇

為了在「完成數位產品端的品牌識別更新」的前提下，在「追求系統未來性」與「避免範疇蔓延」之間取得平衡，我與全體設計師一同定義了本次專案的雙軌目標，並向協作團隊透明化交付標準：

• 🎯 主要目標：確保跨平台數位產品能反映最新品牌識別，提供一致的品牌體驗。
• 🛠️ 次要目標：在不影響主要目標的前提下，進行「最小必要限度」的系統重構，達到：① 色彩定義有單一來源、② 數位產品內的色彩運用有一致性、③ 降低設計端的維護與溝通成本。

同時，我們也明確界定了本次「不做」的事：

• 工程端不導入語意架構。 經設計師、PO 與工程師共同討論後，由工程端決定採取最小變更 —— 只更新既有 Color Library 中的色碼。

專案成果

重構數位產品元件庫的架構，在設計端建立色彩的單一來源

在這四個元件庫之上，我們建立了「GLOBIS 学び放題 Brand Asset」元件庫，於其中定義 Primitive Colors，為所有元件庫的色彩定義提供單一來源。各平台元件庫的 Semantic Colors 皆參照此來源，從根本解決過去「色彩定義分散在各平台元件庫，導致平台之間出現分歧」的問題。

Primitive Colors 的來源有兩種：

• 第一種：品牌色的藍與橘，是以品牌團隊提供的色值為基準，參考 Material Design 的色板生成方式展開為完整色階。
• 第二種：Mono 等非品牌色則不重新定義色值，而是將各平台既有色階的階數與色碼統一，讓四個元件庫在這一層先對齊。

Primitive Colors 只存在於 Brand Asset 中，僅被各平台元件庫引用，而專案設計檔只引用對應平台的元件庫，設計師在實際作業時不會直接取用 Primitive。

在工程端，各平台原本就以接近 Primitive 的方式命名色彩（如 blue_10～blue_100），因此本次的更新是直接替換各色的色碼 —— 在 Primitive 這一層，設計與工程的定義是一致的。但程式碼中仍由各平台各自維護自己的 Color Library，跨平台的單一來源只存在於設計端。

建構色彩語意系統

系統的結構

我們以三個維度建構出一套 Semantic Color 的座標系👇

• 用途
  • 將色彩依用在何處分為 Text、Background、Border 三類，並使用 Variables 的 Scope 功能來依照用途限制各色彩的可用範疇，讓設計師在選色時更省力，也不易誤用。
• 色系
  • 在 Mono、Brand 之外，定義 Success、Error 色系。原本表示成功的綠色與表示錯誤的紅色，在既有系統中是被當作零散的「特殊色」，游離在語意結構之外，本次將它們收進統一的語意命名結構。
• 使用頻率
  • 將同一語意群組內的色彩，依其在既有系統中被使用的頻率由高至低分級（Default、Secondary、Tertiary……）。這裡的使用頻率不等於面積：例如 Primary 的藍很常被使用，但只出現在按鈕等關鍵元件上，在畫面中的面積並不大。
    • 之所以選擇「使用頻率」作為第三個維度，是因為本次的前提是「替換」而非「重新構築」：每一個舊色都必須在新系統中找到對應的位置。以使用頻率排序，能讓最常用的舊色對應到最主要的新色，確保替換後系統的視覺重心不會偏移。
    • 同時，這個維度也讓原本只存在於設計師默契中的使用頻率高低被顯化。某個色彩的使用頻率被表示為表格上的一個明確位置，原本無從查證的高低關係因此變得可見、可被討論。

為什麼是這三個維度，而且是這個順序？

這三個維度與它們的順序，是在我主持的會議中，和設計師們一起決定的。會議中，我們各自用不同的維度與順序（例如 Text/Brand/Mono 與 Brand/Text/Mono）在 Figma 中試做色彩 Variables，比較實際使用時的差異，發現順序會直接影響設計師填色時找顏色的效率。

維度的層級會直接反映在設計師的操作上：在 Figma 中選色時，最高層的維度會是最先出現的選項。因此我們是以「設計師在為元件填色時，實際的判斷順序」來決定維度的排序 —— 先判斷這個顏色用在哪裡（用途），再判斷它屬於哪個語意（色系），最後才是它的使用頻率。

結構的運用

確立上述維度後，我們以「用途 × 色系 × 使用頻率」為軸做出矩陣。這張矩陣同時是盤點工具與替換工具：我們將既有色彩逐一填入表格，確認它在系統中的定位，再為每個舊色選定對應的新色。矩陣讓原本散落在系統中的色彩，其數量與關係變得一目瞭然，方便設計師進行對照。

進行顏色替換時，各平台的設計師先挑出「能涵蓋系統中所有設計 pattern」的代表畫面，運用 Figma 的 Variable Modes 為這些畫面建立可一鍵切換新舊配色的機制。然後，全體設計師在同一個會議上一起檢視各平台的替換結果，交叉 Review 彼此負責的畫面，並確認是否有色彩需要修正。

以代表畫面取代全畫面，是為了在有限的產能下仍能覆蓋系統中的所有樣式；而讓設計師交叉檢視，則是為了確保色彩替換的邏輯在四個平台之間保持一致。

專案成效

上述成效的判斷依據

我並未對上述成效進行量化的評估，而是從設計師日常的工作狀況來判斷：

• 從設計師的工作方式判斷

  矩陣本身已被轉換為 Figma 的 Variables，選色時下拉選單的結構就是這套規則本身；Primitive Colors 不對專案設計檔開放，Scope 也限制了每個色彩能被填在什麼屬性上。

  對設計師而言，這帶來兩個具體的改變：其一，跨平台作業時不再需要先熟悉四套不同的色彩系統，情境切換的耗損減少；其二，選色從「一邊對照其他平台的用色方式再一邊選色」，變成在一個共通的系統中定位。

  不過，這個機制保證的是設計師不會取用系統外的色彩、不會把文字色填進背景；至於要歸到哪一級的判斷，由於第三個維度繼承的是既有色彩的使用頻率，在面對新元件時仍有歧義的空間。

• 從行為判斷

  上表中「系統規範力的延伸」的例子，是我認為最能說明這套系統被團隊內化的一件事。設計師們雖然知道 Toast Message 的顏色長期游離在系統之外，卻一直沒有餘力處理；色彩系統更新後，設計師們自發地提出修正，並爭取到開發端的排程，將它排進 PBI 並上線。這件事不是我要求的，而且它需要付出實際的開發資源 —— 設計師開始把「系統外的色彩」視為應該被收編的對象。

設計之外：工程端的範疇

本次工程端採取的是「於既有 Color Library 中更新色票」的最小變更策略，因此這套色彩語意架構主要落地於設計端。這是專案初期便與 PO、工程師共同界定的範疇：以我們的團隊規模，這類償還技術債性質的任務，本來就難以在常規的開發節奏中被排入；若沒有組織規模或營運方針上的改變，它也不會成為被優先處理的項目。

因此，工程端的色彩系統僅止於 Primitive Colors 的層級。這對我而言也是一次守備範疇的心態練習 —— 畢竟設計師多少都有點完美主義。