回作品列表 公司專案
HZN Design System
讓設計師、PM、工程師共用同一份語言的內部設計系統
- 1
- 唯一手動編輯的來源檔
- 41
- 共用元件
- 3
- 版型殼
- 2
- Tokens 分層架構
背景與挑戰
公司過去的交付流程是「PM 寫 spec → 設計師畫稿 → 工程師重做」，每一段轉手都會走樣；每改一次顏色或間距，設計稿、spec、程式碼三邊還得各自更新一遍。
問題的根源其實是三方沒有共用同一份來源，跟稿精不精細無關。於是我規劃了 HZN Design System——所有設計變數寫在一個 tokens.json，元件樣式共用一套 SCSS，PM 和工程師都直接吃這份來源。改一個檔案，三邊同步更新。
改造前
設計稿 · spec · 程式碼——三份各自更新的真相來源
改造後
改一個 token，三方同步更新——一份來源，零走樣
設計決策
成果與反思
目前 tokens、元件庫、版型殼、產原型流程與 Theme Studio 均已完成，下一步是用真實案子完整跑一輪流程。效果可以濃縮成一句話：改一個 token，三方同步更新；PM 不用等設計師、設計師不用催工程師、工程師不用猜設計意圖。
我也重新定位了 Figma：它只單向接收 tokens，用在還沒有程式的探索與溝通階段；一旦進了 code，code 就是唯一正本，不再反向鏡像養出第二個真相來源。
回頭看，這個專案最有價值的，是與 AI 協作的架構決策過程。tokens 要不要分兩層、給 AI 讀的文件該長什麼樣、為什麼要求 AI「自己讀 repo」而不是把規則貼進對話——每個決策都是在與 AI 來回辯證後定案的。這套「給 AI 的文件」本身也一路演進：一開始是一份大而全的元件速查表，後來把它瘦成精簡索引、把細節下放到每個元件各自的 README，讓 AI 只讀本頁用得到的部分；再加一支 lint 守住文件與實際樣式的一致。設計系統的本體是規則與邊界，而不是元件的長相；能把規則講清楚到 AI 和三種角色都不會誤解，才是這份系統真正的交付物。