一個能夠減少溝通摩擦與
加速產品開發的設計系統

情境

同一個元件，長出好幾種樣子

產品初期以 App 為主，Web 端的元件是隨著需求一塊塊長出來的，彼此沒有共用來源。當企業客戶快速成長、Web 的開發量暴增，問題也跟著浮現，工程師開始頻繁回報：「這個按鈕怎麼跟 A 頁面又不一樣了？」「現在按鈕有好多種版本，到底要用哪一個？」每一次不一致，都變成一次來回確認與重工。

限制

元件散落在各專案，沒有單一來源

深入盤查後發現，同樣的元件被複製在不同專案裡各自維護，專案 A 有一套、專案 B 又有一套，彼此重疊卻不同步，改了一邊另一邊就對不上。而我面對的限制很現實：產品仍在高速迭代、團隊也沒有多餘人力停下來重做設計系統。我必須在「不拖慢產品主線」的前提下，把四散的元件慢慢收斂成一套。

準備工作

先搞懂三種角色各自要什麼

動手前，我先訪談了最關鍵的三方：設計師、工程師、產品經理，想知道他們對元件庫真正的期待。整理後，需求分別落在一致性、模組化，以及清楚的文件紀錄，這也成為我後續取捨的判準。

接著我化身考古學家開始翻歷史檔案、讀工程師的程式碼、反覆把玩產品，再逐一和工程師確認邊界行為。最終盤點出包含樣式、字體、元件共 34 個需要建構的項目，並追蹤每一項的完成狀態，讓整件事第一次有了全貌。

執行

建立設計與工程的共通語言

起初只有 Color System 有明確規範，但 Space、Elevation、Icon 這幾塊完全沒有規則可循，每次用多少間距、陰影要疊幾層，都是憑感覺決定。

過程中我跟工程師討論過要不要引進語義化 Token（例如把顏色分成 primary、danger 這種語意層）也一起做進去。我們的結論是：現階段最急迫的是把「完全沒有規則」的部分補起來，語義化雖然是更完整的做法，但不是當下的痛點，所以先擱置。

執行

列出元件所有的樣貌

過去交付稿件時，元件的狀態常常是我跟工程師吵得最兇的地方。

「沒畫面，就不開發」這是工程師的立場；而我的立場是：同一個元件，本來就該有一樣的互動狀態，不用每個專案都要溝通一次。這個認知落差，讓測試階段變成無止盡的修修補補，花掉大量時間在來回確認「這個狀態到底要不要做」。

所以我參考了 Element Plus 這套成熟的設計系統，把每個元件該有的狀態全部攤開，一次講清楚。工程師開發時不用再問我「這個要不要做」，因為答案已經寫在規範裡了。

執行

說清楚該怎麼用

即使元件的外觀都定義好了，設計師跟 PM 還是常常跑來問我：「這個元件可以用在哪裡？」，他們想知道什麼情境該用、什麼情境不該用，光列出元件的樣貌是猜不出使用邏輯。

所以我參考了 Ant Design，它在每個元件的使用說明上做得很清楚，什麼場景適合、什麼場景要避免，都寫得非常清楚。我照著這個邏輯整理出自己的使用規則，同時也跟 App 端的設計師來回討論，確保 Web 跟 App 在同一個元件上給使用者的體驗一致，而不是兩套各自表述的邏輯。

結果

事情執行的更快，摩擦更少

時至今日設計系統的維護依然在進行，但在完成後的 2、3 個專案就已經看到明顯的成效。

它成為工程師開發時的重度使用工具，交付速度更快、錯誤更少。在某些情況下，原本需要一週才能完成的工作，現在三到四天就能完成。