PixelCake PixelCake
品牌與視覺識別

品牌色彩系統如何銜接 UI 色彩設計與介面規範

品牌色彩系統 ui色彩不只是把 Logo 色套進介面,而是將品牌主色轉換成主色、輔助色、中性色與語意色規則。從按鈕、表單、狀態回饋到對比檢查,建立可維護的 UI 色彩系統,讓品牌辨識、可讀性與操作一致性同時成立。

品牌色彩系統和 UI 色彩設計有什麼關聯?

品牌色彩系統決定品牌如何被辨識,UI 色彩系統則把這些顏色轉成可讀、可操作、可維護的介面規範。兩者必須連動,但不能直接畫上等號。

品牌色常用來建立記憶點,例如 Logo、主視覺、社群版型或廣告素材;UI 色彩則要處理按鈕、表單、導覽、提示、錯誤、成功狀態與不同背景層級。我的判斷是,很多網站看起來「品牌感不一致」,真正問題不在品牌色選錯,而是沒有把品牌色轉換成產品介面能使用的規則。

項目 品牌色彩系統 UI 色彩系統
主要目的 建立品牌識別與記憶點 支援閱讀、操作與狀態回饋
常見使用位置 Logo、品牌素材、簡報、廣告 CTA、文字、背景、邊框、表單
判斷標準 辨識度、一致性、品牌個性 對比、可讀性、元件狀態、維護性

品牌色不是直接套進 UI 的顏色

Logo 色或品牌代表色通常適合在高辨識場景出現,但不一定適合直接放到整個網站或 App。高飽和紅色可能適合品牌記憶,卻可能讓錯誤訊息、促銷標籤和主要 CTA 混在一起;明亮黃色可能適合包裝設計,卻不適合作為白底上的文字色。

比較穩的做法,是先保留品牌主色的色相,再建立不同明度與飽和度的色階,讓它能分別用於背景、按鈕、hover、focus、disabled 與 on-color 文字。

UI 色彩系統要同時服務品牌、可讀性與操作回饋

UI 色彩設計不能只問「好不好看」,還要問使用者能不能讀、能不能判斷狀態、能不能完成操作。品牌辨識、可讀性與操作回饋三者衝突時,介面應優先保住理解與操作。

需求 UI 中的表現 檢查重點
品牌辨識 主按鈕、重點導覽、關鍵視覺區塊 品牌色是否出現在高記憶位置
可讀性 文字色、背景色、卡片 surface 文字與背景是否有足夠對比
操作回饋 hover、active、focus、error、success 狀態是否清楚,不只靠顏色判斷

一套完整的品牌色彩系統應包含哪些 UI 色彩?

可落地的品牌色彩系統至少要包含主色、輔助色、強調色、中性色、背景色、文字色、邊框色與語意色,才足以支撐網站、App、SaaS 或後台介面。

品牌色彩系統進入 UI 後,應該從「幾個漂亮顏色」升級成「一套用途清楚的色彩角色」。每一個顏色都要知道自己服務哪個元件、哪種狀態、哪個層級。沒有用途的顏色越多,品牌一致性反而越弱。

色彩類型 主要用途 常見 token
主色 品牌辨識、主要 CTA Primary
輔助色 次要操作、輔助區塊 Secondary
強調色 少量重點、促銷提示 Accent
中性色 文字、背景、邊框、分隔線 Neutral、Surface、Text、Border
語意色 成功、警告、錯誤、資訊 Success、Warning、Error、Info

主色、輔助色與強調色

主色負責品牌記憶與主要行動,輔助色負責次要層級,強調色只應用在需要短暫吸引注意的位置。60-30-10 配色法則可以作為比例參考:中性色與背景約占多數,品牌主色適度出現,強調色保持克制。

角色 建議比例 適合位置 避免用法
主色 Primary 約 10% 到 20% 主要 CTA、選取狀態、品牌重點 大量鋪滿背景
輔助色 Secondary 約 10% 到 30% 次要按鈕、輔助標籤 搶過主色層級
強調色 Accent 約 5% 到 10% 促銷、提醒、局部高亮 到處標示所有重點

中性色、背景色與文字色

中性色是 UI 色彩系統的骨架。許多介面不好維護,不是品牌色不夠漂亮,而是灰階、文字色與 surface 層級太少,導致每個區塊都要臨時調顏色。

分類 用途 規範重點
Surface 頁面背景、卡片、浮層 至少區分 page、card、overlay
Text 標題、內文、輔助文字 需有 primary、secondary、disabled
Border 分隔線、輸入框、卡片邊界 避免與文字色共用同一組灰階

語意色與功能色

語意色代表系統訊息,不能被品牌色完全取代。成功、警告、錯誤與資訊提示要讓使用者一眼判斷後果,尤其在表單、付款、後台操作和刪除流程中,語意清楚度比品牌感更重要。

語意色 用途 應搭配
Success 完成、通過、儲存成功 確認文案、勾選圖示
Warning 風險、即將影響操作 提醒文字、警示圖示
Error 錯誤、失敗、不可送出 錯誤訊息、欄位標記
Info 補充說明、系統通知 說明文字、提示圖示

如何把品牌色轉成 UI Design Token?

品牌色轉成 UI Design Token 的流程是:建立色階、定義語意用途、命名 token、映射到元件狀態,再交付給 Figma 與前端使用。

這一段是品牌色彩系統能不能真正落地的關鍵。只給一組 HEX,設計師和前端都會各自解讀;給出 token 命名、狀態規則與使用範圍,才可能讓網站、產品與後台維持一致。

  1. 確認品牌主色、輔助色與必要語意色。
  2. 為主色建立 50 到 900 的色階。
  3. 定義 text、surface、border、on-color 等基礎 token。
  4. 把 token 對應到按鈕、表單、導覽與提示元件。
  5. 檢查 light mode、dark mode 與 high contrast 的差異。

從品牌主色建立 50-900 色階

色階不能只靠透明度堆出來。透明度會受到背景影響,同一個 RGBA 放在白底、灰底、深色背景上會呈現不同結果。完整色階應調整明度、飽和度與必要時的色相,形成穩定可預期的顏色。

Token 用途 設計判斷
Primary/50 淡色背景、提示底色 需足夠輕,不干擾文字
Primary/100-200 選取背景、hover 底色 可見但不搶主內容
Primary/500 品牌主色、主要按鈕 通常接近品牌代表色
Primary/600-700 hover、active、深色文字 需要比 500 更有操作回饋
Primary/800-900 高對比文字、深色模式調整 避免濁到失去品牌辨識

定義 on-color、surface、border、text token

on-color 是放在色塊上的文字或圖示顏色,例如 on-primary 代表主色按鈕上的文字色。這個 token 很容易被忽略,但它直接影響 CTA 是否可讀。

Token 名稱 用途 範例
color.primary.500 主品牌色 主要按鈕背景
color.on-primary 主色上的文字與圖示 按鈕文字
color.surface.default 預設頁面背景 網站主背景
color.surface.card 卡片或區塊背景 商品卡、設定面板
color.text.primary 主要文字 標題、正文
color.border.default 一般邊框 輸入框、分隔線

把 token 對應到按鈕、表單、導覽與提示元件

token 的價值在於可重複映射到元件狀態。按鈕不能只有 default,表單不能只有 border,導覽不能只有 active。每個狀態都要有顏色、用途與對比檢查。

元件 狀態 建議 token 檢查重點
主要按鈕 Default primary.500、on-primary 文字可讀,層級明確
主要按鈕 Hover primary.600 使用者感覺得到變化
主要按鈕 Disabled neutral.200、text.disabled 不可操作狀態清楚
表單欄位 Error error.600、surface.error 需搭配錯誤文字
導覽項目 Active primary.50、primary.700 目前位置可辨識

品牌色和語意色衝突時怎麼處理?

品牌色和語意色衝突時,應優先保留狀態辨識,再用色相、明度、圖示、文案與元件位置拉開差異,避免使用者誤判操作後果。

紅色品牌、綠色品牌、黃色品牌最常遇到這個問題。錯誤訊息、成功狀態和警告提示本來就帶有強烈語意,如果它們和品牌主色太像,介面會看起來統一,卻讓使用者更難判斷。

品牌主色是紅色時,Error 不該長得一樣

品牌紅可以繼續用於 CTA 或品牌重點,但 Error 應另建一組更偏功能提示的紅色系,並搭配圖示與錯誤文字。我的經驗是,只靠把 Error 調深一點通常不夠,因為使用者看到的仍是同一個品牌紅。

情境 風險 修正方式
紅色主按鈕與錯誤提示同色 錯誤訊息被誤認為品牌強調 Error 使用不同色相或更高明度差
刪除按鈕與主要 CTA 都是紅色 破壞性操作不夠明確 加入 danger token、警示圖示與確認文案
表單錯誤只改邊框紅色 色弱使用者可能看不出差異 加上錯誤文字、圖示與欄位說明

品牌主色是綠色時,Success 需要另一套語意規則

綠色品牌常讓 Success 狀態失去辨識,因為整個介面本來就大量使用綠色。解法不是完全放棄綠色,而是讓 Primary 和 Success 分別有不同色階、不同圖示語言與不同文案。

情境 風險 修正方式
綠色 CTA 與成功訊息同色 使用者分不清行動與結果 Success 使用較深或較柔和的綠色
確認狀態只顯示綠色背景 狀態含義不清楚 搭配「已完成」文案與勾選圖示
所有正向訊息都用品牌綠 品牌色被功能訊息稀釋 Primary 保留給操作,Success 保留給結果

UI 色彩系統如何符合可讀性與無障礙?

UI 色彩系統要符合無障礙,必須檢查文字對比、互動狀態、非顏色提示、focus state 與色盲情境,不能只看視覺風格。

WCAG 是常見的無障礙參考標準。一般文字的文字與背景對比通常應達到 4.5:1,大字與重要圖形元件通常至少要達到 3:1。這些門檻不是美感建議,而是讓更多使用者能順利閱讀與操作的基本條件。

文字與背景對比要達到基本門檻

色彩 QA 應該在設計階段就做,不要等到前端完成才發現 CTA 文字不清楚。尤其是品牌主色偏亮、偏黃、偏粉時,白字放上去很容易不達標。

檢查項目 建議門檻 常見問題
一般文字 至少 4.5:1 灰字太淡、背景太接近
大字或粗體大標 至少 3:1 品牌色標題在淺底上不清楚
按鈕文字 依文字大小檢查 4.5:1 或 3:1 主色太亮導致白字不足
輸入框邊界 需要能辨識可操作範圍 邊框灰太淡,欄位像純文字

互動狀態不能只靠顏色表示

連結、表單錯誤、focus、禁用狀態都不能只靠顏色傳達。對色盲、低視力或在強光環境中使用的人來說,顏色差異可能不足以判斷狀態。

元件 不建議做法 較穩做法
連結 只用藍色區分 加底線或明確 hover 樣式
表單錯誤 只把欄位邊框改紅 加入錯誤文字、圖示與 aria 說明
Focus state 移除外框 使用清楚的 focus ring
Disabled 只降低透明度 調整文字、背景與游標狀態

深色模式下,品牌色要怎麼重新映射?

深色模式不能直接反轉淺色模式的顏色,而要重新映射 surface、text、border、primary 與語意色,確保品牌感、層級與對比都成立。

同一個品牌色在白底與深色背景上的感受會不同。淺色模式中剛好的藍色,到了深色模式可能過亮;淺底可讀的灰字,到了深底可能完全失去層級。深色模式需要獨立 token mapping,而不是把 HEX 原封不動搬過去。

深色 UI 不建議使用純黑作為唯一背景

純黑可以用在特定高對比介面,但作為唯一背景容易讓層級變硬,卡片、彈窗、導覽和輸入框都難以區分。多數產品介面更適合使用深灰 surface 建立層次。

Token 用途 規則
surface.dark.base 頁面背景 使用接近黑的深灰,不必固定純黑
surface.dark.raised 卡片、面板 比 base 稍亮,建立 elevation
surface.dark.overlay 彈窗、下拉選單 需與背景有清楚邊界
border.dark.default 深色邊框 避免亮到像輸入焦點

高飽和品牌色在深色背景上要降飽和或調亮度

高飽和品牌色在深色背景上很容易刺眼。深色模式的 primary token 可以保留品牌色相,但調整飽和度、亮度與對比,讓它看起來仍像同一個品牌,同時不干擾閱讀。

淺色模式 token 深色模式對應 調整理由
primary.500 primary.dark.400 在深底上提高可見度但避免刺眼
primary.50 primary.dark.surface 淡色背景需改成深色提示底
text.primary text.dark.primary 文字需在深底上保持足夠對比
border.default border.dark.default 深色邊框不能沿用淺色灰階

品牌色彩系統如何交付給設計師與前端?

品牌色彩系統交付時,應同時提供 Figma styles、Design Token 命名、CSS variables、Tailwind 對應與使用規則,避免設計稿和前端實作各走各的。

真正可維護的交付,不是丟一份品牌手冊 PDF 就結束。設計師需要可套用的 styles 和 variables,前端需要穩定命名與主題映射,產品團隊需要知道哪些顏色可以新增、哪些只能沿用。

Figma styles 應該怎麼命名

Figma 命名要讓人一看就知道用途,而不是只看到顏色名稱。建議以角色、層級、狀態命名,讓設計稿與元件庫可以長期維護。

類型 命名範例 用途
品牌色階 Color/Primary/500 品牌主色基準
文字 Color/Text/Primary 主要文字
背景 Color/Surface/Card 卡片背景
邊框 Color/Border/Default 一般分隔與輸入框
狀態 Color/State/Error 錯誤提示與欄位

CSS variables / Tailwind config 應該怎麼對應

前端命名要穩定、可主題化,並能對應設計端語意。CSS variables 適合處理 light mode、dark mode 與品牌主題切換;Tailwind config 則適合把 token 放進工程團隊既有的 class 工作流。

:root {
  --color-primary-500: #3b63f6;
  --color-on-primary: #ffffff;
  --color-surface-default: #ffffff;
  --color-text-primary: #171717;
  --color-border-default: #d4d4d4;
  --color-error-600: #dc2626;
}

[data-theme=“dark”] { —color-primary-500: #7c9cff; —color-surface-default: #111111; —color-text-primary: #f5f5f5; —color-border-default: #3f3f46; }

Tailwind 對應時,不建議讓 class 直接綁死品牌 HEX。較好的方式是讓 Tailwind 指向 CSS variables,日後品牌微調或深色模式切換時,不必改每個元件。

常見 UI 色彩系統錯誤與診斷方式

常見 UI 色彩系統錯誤包括 CTA 不突出、灰階不足、狀態色混淆、disabled 不可讀、只靠透明度處理狀態,以及顏色過多削弱品牌一致性。

如果介面看起來雜亂,先不要急著換品牌色。更有效的檢查順序是:主色用途是否清楚、語意色是否分離、中性色是否完整、狀態是否有規範、token 是否能交付給前端。

問題 可能原因 修正方式
CTA 不突出 主色與背景對比不足 調整 primary 色階與 on-primary
灰階不夠 文字、背景、邊框共用太少顏色 建立 text、surface、border token
狀態不清楚 品牌色與語意色混用 分離 primary、success、error
Disabled 不可讀 只用 opacity 降低透明度 定義 disabled 背景與文字色

顏色太多,導致品牌感變弱

顏色過多通常是治理問題,不是創意問題。每新增一個顏色,都應該回答它服務哪個用途、是否能被既有 token 取代、是否會破壞品牌主色的辨識位置。

診斷問題 判斷方式 刪減原則
是否有多個相近藍色 比對用途是否重複 合併到同一組 primary 或 info
是否每個活動都新增顏色 檢查是否只為短期素材服務 改用 accent 或 campaign token 管理
是否設計師各自取色 檢查 Figma 是否有未命名色票 未命名色票需回收或納入 token

只用透明度處理所有狀態

RGBA 和 opacity 可以輔助狀態設計,但不能取代完整色階。透明度會被底色影響,也容易讓 disabled、hover、overlay 和邊框狀態互相干擾。

錯誤做法 問題 修正方式
hover 只加黑色透明層 不同背景下結果不一致 使用 primary.600 或 surface.hover
disabled 只設 opacity 50% 文字可能低於可讀門檻 定義 text.disabled 與 surface.disabled
所有提示底色都用主色透明度 語意色被品牌色蓋掉 建立 success、warning、error 淡色底

不屬於本文範圍的內容

品牌色彩系統進入 UI 的重點是介面落地,因此 Logo 設計、完整品牌識別手冊、印刷製程、圖片素材規劃與色彩心理學大全都不屬於這個主題範圍。

  • Logo 造型設計與商標繪製流程。
  • 完整品牌識別規範書的章節規劃。
  • 印刷製程、紙材、特殊色票的深度教學。
  • 圖片素材、攝影風格與 AI 圖片生成規劃。
  • 只談情緒聯想、沒有 UI 決策用途的色彩心理學。

品牌色彩系統和 UI 色彩系統一樣嗎?

不完全一樣。品牌色彩系統負責品牌辨識與一致性,UI 色彩系統則負責介面可讀性、操作狀態與前端維護。兩者應該共享品牌基礎,但 UI 端需要額外定義色階、語意色、surface、text、border 與元件狀態。

Logo 顏色可以直接當網站或 App 的主色嗎?

可以作為主色基準,但不建議直接套用到所有 UI。Logo 色需要先檢查對比、可讀性、按鈕文字、hover、深色模式與語意色衝突,再決定要用原色、調整後的 primary.500,或另建 UI 色階。

品牌主色需要做幾個色階才夠?

常見做法是建立 50 到 900 的色階,至少要能支援淡色背景、主要按鈕、hover、active、深色文字與深色模式映射。小型網站可以先做較精簡版本,但仍應保留淺、中、深三種層級。

UI 色彩系統一定要有語意色嗎?

需要。只要介面包含表單、登入、付款、設定、後台或任何需要回饋的操作,就應該有 Success、Warning、Error、Info。語意色能降低誤解,特別是在錯誤提示與不可逆操作中很重要。

如果品牌色是紅色,錯誤訊息要怎麼設計?

品牌紅和 Error 應該拉開辨識距離。可以讓 Error 使用不同色相傾向、不同明度、專屬 danger token,並搭配錯誤圖示與明確文案。刪除、失敗、表單錯誤不應和品牌 CTA 長得一樣。

深色模式可以直接把淺色模式反轉嗎?

不建議。深色模式需要重新映射 surface、text、border、primary 與語意色。直接反轉容易造成品牌色刺眼、背景層級不足、文字對比不穩,也會讓陰影與邊框失去原本的視覺功能。

HEX、RGB、RGBA、CMYK、Pantone 有什麼差別?

HEX、RGB、RGBA 多用於螢幕介面與前端實作,RGBA 多了透明度。CMYK 主要用於印刷,Pantone 常用於品牌色票與實體輸出管理。UI 色彩系統通常以 HEX、RGB、CSS variables 與 Design Token 為主要交付格式。

RGBA 透明度可以取代色階嗎?

不適合取代。RGBA 會受到底色影響,同一個透明度在不同 surface 上會有不同結果。色階則能提供更穩定的明度與飽和度控制,適合用於按鈕狀態、提示底色、文字與深色模式。

UI 色彩要怎麼檢查無障礙對比?

先檢查文字與背景對比,一般文字通常以 4.5:1 作為基本門檻,大字或重要圖形元件通常至少 3:1。接著檢查 focus ring、表單錯誤、連結與狀態提示是否不只依賴顏色。

品牌色彩系統要怎麼交付給前端工程師?

應提供 token 命名、HEX 或 RGB 值、CSS variables、深色模式映射、元件狀態表與使用限制。若團隊使用 Tailwind,也可以把 token 對應到 theme 設定,但仍建議保留語意命名,避免直接依賴顏色名稱。

小品牌或新創需要完整 UI 色彩系統嗎?

不一定一開始就需要大型設計系統,但至少應該有主色、文字色、背景色、邊框色、錯誤色與按鈕狀態。越早定義基本 token,後續新增頁面、活動頁或產品功能時越不容易失控。

品牌色彩系統應該多久檢查或更新一次?

建議在品牌改版、網站改版、產品介面擴充、導入深色模式或無障礙檢查不通過時重新檢查。若產品持續迭代,也可以定期盤點未命名色票、重複色階與元件狀態,避免色彩規範逐漸失準。