把同一個品牌的官網、App、上台簡報攤開來看，色彩深一點淺一點、字體有的圓潤有的方正、按鈕形狀從直角到全圓角都出現過，乍看像是三個不同單位各自做出來的東西，其實常常出自同一間公司。這種落差多半不是設計師不用心，而是每個介面都在各自的專案裡重新做一次決定，這次按鈕該多圓、那個藍色究竟是哪一組色碼，彼此都沒有人回頭比對過。
問題的根源，往往不在美感，而在缺一套所有人都依循的規則——這正是設計系統（Design System）要解決的事。它不是一份好看的樣式頁面，而是把顏色、字體、元件到維護方式全部收進同一套標準裡，讓不同的人做出來的東西還是同一種語言。國外使用者體驗研究機構 Nielsen Norman Group 就指出，設計系統能讓一致性延伸到不同產品、不同管道，甚至跨越彼此獨立運作的部門。
先從它真正的定義，還有它跟你可能聽過的 UI Kit、元件庫差在哪裡講起，再一路拆到怎麼從零開始建立一套。
設計系統是什麼？
設計系統，簡單說，是一套用來大規模管理「設計一致性」的完整標準，靠的是可以重複使用的元件與規則，不是靠設計師每次重新畫一次。使用者體驗研究機構 Nielsen Norman Group 把它定義為一整套完整標準，目的是用可重複使用的元件與模式在規模化的情況下管理設計；Figma 官方部落格則形容它是一組「建構模組與標準」，用來讓產品和體驗的外觀感覺維持一致。兩邊講法用詞不同，指的其實是同一件事。
這裡最容易被誤會的一點是，好看從來不是設計系統的目的，減少重複工、降低團隊溝通成本、讓品牌不管出現在哪裡都像同一家做的，才是它真正要處理的問題。畢竟樣式頁面做得再美，如果沒有規則規定按鈕圓角該多少、什麼情境該用哪個顏色，下一個接手的人還是會自己決定一次，一致性照樣守不住。
把這套標準拆開來看，通常由四個部分組成：一套共同的設計原則、把顏色字體變成規則的 Foundation、收著重複元件的元件庫，還有負責維護這一切的文件與治理機制。以下先從設計原則拆起，再一路往下講。
設計原則：介面決策背後的共同判斷邏輯
設計原則常被誤會成掛在牆上的標語，例如「簡潔」、「一致」這種放在哪裡都通用的形容詞，但真正有用的原則其實是團隊做取捨時能拿出來用的判斷依據。同樣是做後台管理系統，團隊在乎的多半是資訊密度夠不夠高、操作會不會出錯；換成消費型 App，在乎的可能變成引導順不順、情緒回饋夠不夠即時。這兩種產品的原則會長得完全不一樣，卻都同樣具體。
有了這一層依據，遇到「這個按鈕該不該加陰影」這種爭論時，團隊才有一個共同的標準可以拿出來討論，不是各憑主觀喜好各說各話。Nielsen Norman Group 在拆解設計系統的組成時，也把風格指南與設計原則列為其中重要的一塊。
Foundation：把顏色、字體變成大家都能用的規則
設計系統裡的「Foundation」這一層，處理的是最基本的視覺決策：顏色、字體、間距、圓角這些會反覆出現的值。做法是把它們抽象成一組有名字的變數，也就是設計代幣（Design Token）。與其在每個檔案裡各自寫一串色碼，不如統一叫它「主要行動色」，讓設計工具和實際上線的程式碼共用同一個名字，之後要調整，一次改完全部同步。
這件事其實還在持續成熟，不是老早就定案的舊觀念。全球資訊網協會（W3C）旗下的 Design Tokens 社群小組，一直到 2025 年 10 月才公布第一個正式穩定版規格，讓不同設計工具之間終於有共通格式可以互通；Google 的 Material Design 3 官方文件裡，也把 design token 列為建立一致視覺語言的基礎環節。換句話說，Design Token 讓顏色字體從各自記在腦子裡，變成寫進系統裡大家都能查。
元件庫：重複出現的畫面收進同一個地方
元件庫做的事，是把按鈕、輸入框、卡片這些反覆出現的介面元素，整理成可以重複取用的模組，而不是每次做新頁面都重畫一次。一個夠完整的元件項目，至少要交代清楚名稱、用途說明、可以調整的屬性，還有預設、滑過、停用這幾種不同狀態長什麼樣子，最好再附上對應的程式碼片段，讓工程師拿到就能直接串接。
隨手截幾張元件示意圖，貼成一份文件，並不能算是元件庫，少了狀態說明和程式碼，工程師照樣得自己猜。Nielsen Norman Group 在拆解元件庫的組成要件時，就把名稱、說明、屬性、狀態、程式碼片段這幾項列為缺一不可的基本盤。
文件與治理：讓規範不只是好看的網頁
沒有文件、也沒有人維護的元件庫，遲早會變成沒人搞得清楚哪個才是最新版本的倉庫，新加入的設計師不知道能不能用，工程師也不敢貿然套用舊元件。
至少要有人固定負責審核新提交的元件、更新舊規格、淘汰過時的項目，這個角色不必是一整個部門，但責任歸屬要明確，不能大家都能改、卻沒人真的負責。Nielsen Norman Group 建議設計系統團隊的最低配置，至少要包含一位互動設計師、一位視覺設計師與一位工程師，才撐得起長期維護的工作量。
設計系統和 UI Kit、元件庫，有什麼差異？
這三個詞常被混著用，其實範圍完全不一樣。UI Kit 通常是設計工具裡一份現成的視覺素材集合，裡面有按鈕、圖示、色票，方便設計師快速拼出畫面草稿，但它不會告訴你「什麼情境該用哪一個」，也不含維護和更新的機制，比較像一箱現成零件。
元件庫解決的是另一個問題，把這些介面元件做成可以重複呼叫的模組（不論是設計檔裡的元件，還是前端程式碼裡的元件），讓「怎麼做出來」這件事不用每次重來。可是元件庫同樣不包含決策原則，也沒有規定誰該負責維護，它比 UI Kit 更進一步，但還沒到系統的完整程度。
設計系統則是把 UI Kit 的素材、元件庫的模組，再加上前面講的設計原則、文件與治理流程，全部整合成一套完整的運作方式。可以想成 UI Kit 是零件箱、元件庫是半組裝好的半成品，設計系統才是連同使用說明書一起交給你的完整包裹。Nielsen Norman Group 在比較設計系統與風格指南時，把設計系統定位成「母體」，風格指南、模式庫、元件庫則是被包在裡面的子集，元件庫可以是設計系統的一部分，但一份元件庫並不會自動等於一整套設計系統。
設計系統跟 Style Guide 又有什麼不同？
還有一個常被混用的詞是 Style Guide（風格指南），它只處理視覺規範，包括顏色、字體、語氣這些看得到的層面，是設計系統裡的一個子集，不含元件本身，也不含程式碼規則。理解這一層之後，前面提到的三個詞彼此的關係就清楚了。設計系統是最大的容器，Style Guide、UI Kit、元件庫都只是其中一塊拼圖，彼此不是互相競爭的替代品，而是各自負責一部分。
設計系統通常怎麼從零開始建立？
知道設計系統長什麼樣子之後，下一個問題是它實際上怎麼從零開始建立起來。整套邏輯其實不複雜，先盤點現有介面找出不一致的地方，把常用的視覺決策定成 Design Token，把重複出現的元件收進元件庫，最後寫清楚文件和治理規則，讓系統能持續被維護，而不是做完就束之高閣。
要提醒的是，這四步做完並不是終點。Nielsen Norman Group 特別點出，設計系統會隨著使用它的人持續回饋而不斷演進，上線的第一版，反而才是真正開始被使用、被檢驗的起點。
步驟一：先盤點現有介面，抓出不一致的地方
第一步是把現有產品的畫面全部攤開來看，不管是網站各個頁面，還是 App 裡的各個畫面，一頁一頁列出來或截圖比對，找出同樣功能卻長得不一樣的地方。最常見的例子是同樣是「確認」按鈕，卻在不同頁面出現好幾種顏色和大小，使用者未必說得出哪裡不對，但點下去的感覺就是不太一樣。
這一步的重點是先看清楚問題有多大，不是急著動手畫新元件。沒盤點清楚就直接開始定規則，很容易漏掉真正常出現的落差，反而白費工夫。
步驟二：把常出現的顏色、字體、間距訂成 Design Token
第二步是把盤點出來、真正會反覆用到的視覺決策抽象成一組有名字的變數。這一步做完，設計檔裡使用的顏色和實際上線的網頁、App 就能共用同一套命名，之後要調整品牌主色，或是要做深色模式，都不必再逐頁手動修改一次。
沒有這一層，設計師改了一次顏色，工程師端卻可能還在用舊的色碼，兩邊各自維護一份，遲早會對不上。
步驟三：把重複出現的按鈕、表單收進同一個元件庫
第三步是把前一步統一好視覺規則的元件，例如按鈕、輸入框、卡片，整理進元件庫，並且定義好每個元件在不同狀態下該長什麼樣子。這一步做完，設計師和工程師都能直接取用現成的元件，不用每次遇到新頁面就重畫一次、重寫一次。
省下的不只是時間，還有因為各自理解不同而做出的落差，同一個輸入框，這頁圓角六像素、那頁圓角十像素，這種細節差異最容易被使用者感覺到卻說不出原因。
步驟四：寫清楚使用規則，決定誰能新增、誰負責維護
第四步最容易被跳過，卻是最關鍵的一步，也就是寫清楚使用規則，決定誰能新增元件、誰負責審核、誰在系統過時的時候要動手更新。少了這一步，前面三步做出來的規則和元件庫，很快就會沒人知道能不能用、能不能改，前面的努力也很難維持住。
至少要指定人固定負責審核新元件、更新舊規格、淘汰不再使用的項目，讓系統長期活著，而不是上線當天就是它最完整的樣子。
同一個品牌，官網、App、簡報卻各自為政
把視角拉回最開頭的畫面。一個持續成長中的團隊，官網多半是某個時期的設計師做的，App 後來換了一批人接手，簡報又是行銷部門自己排版，三邊各自負責，久了顏色深淺、字體粗細、按鈕形狀全部對不上。使用者未必說得清哪裡不對勁，但下意識會覺得「這個品牌怎麼有點不太一樣」。
導入設計系統之後，這三個介面才開始共用同一套顏色、字體、元件規則，看起來才會像出自同一個地方，而不是三個部門各憑印象拼湊出來的結果。
如果想看真實上線的設計系統長什麼樣子，幾個國際知名品牌都公開發布了自己的版本可以查閱，例如 Google 的 Material Design、IBM 的 Carbon Design System、Shopify 的 Polaris，還有 Atlassian Design System。這裡列出來單純當作參考點，不是要比較誰做得比較好，而是讓你知道「原來實際做出來是這個樣子」。
設計系統從來不是一份做完就能收工的文件，而是一套讓不同的人做出一致體驗的長期工作方式。與其一次寫出一本完美的規範書，不如先從統一一顆按鈕的圓角、訂好一組顏色代碼開始收拾起，這種小範圍的整理反而更容易堅持下去，也更容易看到成效。
回到最開頭的畫面，目標其實很單純，讓同一個品牌不管出現在官網、App，還是台上那份簡報，看起來都像同一家做出來的東西。