Design System

設計系統是什麼，跟「元件庫」是同一件事嗎？

設計系統跟元件庫經常被混用，但兩者範圍不同。元件庫是一堆可重複使用的程式碼區塊（按鈕、輸入框、卡片），它告訴你「有什麼可以用」；設計系統則更完整，除了元件本身，還包含使用規則與原因——什麼情況該用按鈕、什麼情況該用連結，色彩系統背後的意義是什麼，無障礙標準怎麼套用——它回答的是「什麼時候用、為什麼這樣設計」，不只是「有哪些零件」。

打個比方：元件庫像是一個裝滿窗戶、門、磁磚的建材型錄；設計系統則是連同「這棟房子的建築規範」一起給你——不只告訴你有哪些建材，還告訴你怎麼組合起來才會是同一種風格、同一套標準。

設計系統為什麼會被特別建立出來，它解決了什麼問題？

產品規模一大，同一個團隊裡不同人畫出來的按鈕顏色、間距經常會慢慢分歧——不是故意的，是因為每個人各自做決定，時間久了就累積出「同一個產品裡有五種藍色」這種狀況。設計系統要解決的核心問題，就是讓設計和開發雙方有一個共同對照的來源，減少「這個顏色到底是哪個藍」這類重複溝通，也降低介面風格隨著團隊擴大而逐漸失控的風險。

對開發端而言，設計系統帶來的另一個好處，是理論上能達到「幾乎無損的交付」——如果設計稿用的元件跟工程師手上的程式碼元件是同一套，交接時就不需要重新猜測規格，設計改版時也能同步更新，不用兩邊各自維護一份、容易對不上。

設計系統實際上由哪些部分組成，怎麼運作？

一套完整的設計系統通常包含幾個層次：

1. 設計代幣（design tokens）：最基礎的原子單位，例如色彩、字級、間距的具體數值，這些數值同時存在於設計工具與程式碼裡，兩邊引用同一組數字
2. 元件庫（component library）：把設計代幣組合成可重複使用的介面元件，例如按鈕、輸入框、卡片
3. 使用規範／文件：說明每個元件何時該用、何時不該用，例如按鈕跟連結的使用時機差異、無障礙標準怎麼套用
4. 治理流程：誰有權限新增或修改元件、變更怎麼審核、版本怎麼管理，這一層決定設計系統會不會隨時間累積技術債

Shopify 的 Polaris 是常被引用的實例：它一開始只是元件庫，後來擴展成完整的模式系統與設計系統，同時服務設計師和開發者，並提供版本控制，讓團隊能在多個產品之間維持一致但可擴展的體驗。

如果你用 Claude 或其他 AI 工具生成設計稿，設計系統這件事跟你有什麼實際關係？

如果團隊已經有設計系統，AI 生成介面時最有價值的用法，是讓它讀取既有的設計代幣與元件規則，而不是每次都從零開始生成一套新的視覺風格——這樣產出的東西才會跟現有產品維持一致，而不是變成一個風格獨立、跟主產品格格不入的孤島。如果團隊還沒有設計系統，用 AI 快速產出多個方向時，反而要注意不要讓每個方向各自累積出不同的色彩、間距慣例，否則等於在還沒建立系統前就先製造了更多不一致。

實務上比較務實的順序，是先確認有沒有既有設計系統可以餵給 AI 工具參照，沒有的話，先用小範圍的探索定案基礎代幣（顏色、字級、間距），再讓 AI 在這個基礎上延伸產出，而不是讓每一次生成都各自發明一套新的視覺語言。