讓 Figma、Storybook、產品和 AI 說同一種語言

1ContextAI 讓產出變快，也讓我們重新檢視哪些流程可以被省略

當產出變快，過去的重複工作也變得更明顯

AI 改變了設計開始的方式。以前設計師通常要先畫 wireframe，再做 UI mockup，最後交給前端重新實作；但現在 AI 可以協助設計師直接用接近正式產品的程式碼做 prototype，讓我們開始重新思考：這些中間步驟是不是都還有必要？

這不是 AI 製造了新的重工，而是 AI 讓我們更清楚看到，設計到工程之間原本就有很多手工轉譯。當 prototype 已經越來越接近產品實作，團隊自然會開始問：哪些工作只是為了補設計和工程之間的落差？哪些其實可以被省掉？

但要做到這件事，設計師、工程師、產品和 AI 必須看同一套元件來源。否則 AI 生成得再快，後面還是可能要重新整理 Figma、重新確認元件規格；工程師也還是要判斷該用新版元件，還是舊版元件。

對 1.Talk 來說，這個問題更明顯。新版元件庫和 Storybook 已經建立，但正式產品裡還有很多頁面使用舊元件，導致 Figma、Storybook、產品和 AI 看到的是不同版本：

• 設計師改了樣式，產品不一定同步
• 工程師不知道該用新元件還是舊元件
• AI 生成介面時，也可能引用即將淘汰的元件

所以這個專案真正要解的，不是「再做一套設計系統」，而是找到一個能讓設計、工程、產品與 AI 共同對齊的橋樑。

問題不是沒有工具，而是缺少共同判斷標準

後來我們發現，Storybook 很適合成為這個共同參考點。它不只是工程師查看元件的地方，也可以讓設計師確認元件狀態、工程師查看實作方式，並讓 AI 依照同一套規則生成介面。當大家都透過同一個來源判斷，設計系統才真的能進入日常交付流程。

2Insight真正需要整理的，是設計和工程之間的共同語言

這個案子的關鍵不是再補一份文件，而是建立一套可以被設計師、工程師和 AI 共同執行的元件語言。當 prototype 越來越接近正式產品，過去依靠人工確認的交付方式就會變成瓶頸。

真正需要整理的，是讓每個角色都能在同一套規則下判斷：現在該用哪個元件、哪些狀態是正確的、什麼時候可以安全替換。

這也讓我意識到，這個案子的本質不是新增功能，而是在使用者幾乎沒有感覺的情況下，把產品底層慢慢換掉。建立新系統不難，難的是讓舊系統安全退場。

3Design challenge要換底層元件，但不能讓使用者有感

這次遷移最難的地方，不是把新元件做出來，而是要在不影響日常使用的情況下，把產品底層慢慢換掉。

1. 常用頁面不能被改壞：預約、會員、AI Agent 這些功能每天都有人在用，畫面不能因為換元件而跑版，操作也不能突然失效。
2. 使用者原本的操作習慣不能被打斷：元件可以更新，但按鈕在哪裡、流程怎麼走、使用者原本熟悉的操作節奏，都要盡量維持穩定。
3. 團隊不能在遷移中迷路：新舊元件並存時，設計師、工程師和 AI 都要清楚知道現在該用哪一套元件，才不會一邊整理、一邊製造新的混亂。

4Strategy先對齊規則，再一步步替換

因為這不是換掉某一個元件就能解決的問題，我把做法拆成三件事：

1. 先讓大家看同一套元件：把 Storybook 當成共同參考，不管是設計師、工程師、產品，或是 AI，都要知道現在該依照哪一套元件來做。
2. 分開檢查元件和產品畫面：元件本身要先確認長得對；放回產品頁面後，也要再確認畫面和操作沒有被影響。
3. 用清單追蹤進度，慢慢換掉舊元件：每個頁面改到哪、哪些元件還沒換、哪個版本已經發布，都要看得見，才不會有人改了、但其他人不知道。

5Solution 1把 Storybook 變成設計、工程與 AI 的共同語言

第一步，是把 Storybook 從「工程師看的元件文件」，變成大家共同參考的地方。

設計師可以用它確認元件有哪些狀態和變體，工程師可以用它查看實作方式，AI 也可以依照這些規則生成介面。當大家都看同一個地方，設計系統就不只是文件，而是真的能進入日常交付流程。

這次和一般設計系統整理比較不一樣的地方是：我們不只是在整理給設計師和工程師看的元件規格，也是在整理一套 AI 可以照著使用的規則。

更進一步，設計師也不再只是提出需求，而是可以透過 AI 協助，直接參與元件庫維護：從開發、檢查程式是否正常、code review 到開 PR，都可以由設計師主導。工程師主要協助環境設定和發版。

所以這套規格不只是文件，而是實際會影響產出的規則。例如顏色要從 token 來、不能直接寫死色碼、每個元件都要有展示頁。這些規則越清楚，AI 在協助開發時就越不容易做錯。

6Solution 2「視覺一致」與「行為不變」分開驗證

換元件的風險，不只是不確定「新元件長得對不對」，也要確認「放回產品後，會不會影響原本的使用體驗」。

所以我們把檢查分成兩層：

1. 先看元件本身：用 Chromatic 在 Storybook 裡比對 Button、Input、Modal 等元件，確認新元件的樣子符合預期。
2. 再看產品畫面：用 Preview Link 回到實際產品頁面檢查，確認間距、顏色層級和操作流程都沒有被影響。

這樣我們就可以分開判斷兩件事：元件有沒有改對，以及產品用起來有沒有維持穩定。

7Solution 3把「換到哪裡了」變得看得見

舊元件分散在很多產品頁面裡，不能一次全部換掉。如果沒有追蹤清單，很容易變成有人改了一部分，但其他人不知道目前進度。

所以我們把遷移拆成三種追蹤方式：

1. 頁面清單：標記每個頁面是已完成、進行中，還是還沒開始。
2. 元件任務：每次設計系統發新版後，依照這次有變動的元件建立任務，讓前端可以逐步替換產品裡的 Button、Input、Modal 等舊元件。
3. 獨立發版：設計系統先自己發版，不要求產品立刻跟著更新。AI 會先建議版本類型，人確認後再發版；產品端等準備好時，再更新到新版本。

這樣大家就能知道目前換到哪裡，也能把大型替換拆成比較安全的小步驟。

這份清單不只是進度表，而是新舊元件並存時的判斷依據。設計師可以知道哪些頁面已經能使用新版元件，工程師可以依照元件任務逐步替換，產品端也能確認目前更新到哪個版本，避免同一個元件在不同頁面被重複判斷。

8它改變了整個交付流程

這個專案最大的改變，不只是讓設計做得更快，而是讓一些原本習慣要做的步驟，變得不一定需要。

過去，設計師通常要先做 wireframe，再做 UI mockup，接著做 prototype；前端拿到設計稿後，還要再把畫面重做一次。每個階段之間都要開會確認，也很容易因為理解不同而來回調整。完整交付通常需要約 5 天。

當 Storybook 變成設計和工程之間的共同參考後，設計師可以直接用接近正式產品的元件做 prototype。前端也不需要重新理解畫面、重刻 UI，而是可以在同一套元件基礎上接 API 和產品邏輯。交付流程因此縮短到 2 天。

真正省下來的，不只是時間，而是這些重複工作：

• wireframe
• UI mockup
• 前端重刻畫面

目前這套流程已支援約 40 個元件，服務設計與前端共 11 位日常使用者。也回應了這個專案最初的問題：AI 讓設計師能更快做出 prototype，而 Storybook 讓 prototype 和正式產品之間不需要再重做一次。

9Outcome

這個專案最後不只是做出一套新的元件庫，而是讓設計系統真的進到日常交付流程裡。

過去，Figma、Storybook、產品和 AI 看的來源不一樣，設計和工程之間需要靠很多人工確認來維持一致。透過這次遷移，我們把元件規則收斂到 Storybook，讓設計師、工程師和 AI 都能依照同一套規則工作。

對團隊來說，設計系統不再只是用來「維持畫面一致」的文件，而是變成一套可以支撐 prototype、開發、驗收和發版的工作方式。

10Reflection

這個專案讓我重新理解設計系統的價值：它不是把元件整理得更漂亮，而是讓團隊可以用同一套規則交付產品。

過去我以為設計系統的重點是「建立」；實際推進後才發現，真正困難的是「收斂」。也就是讓舊元件安全退場，讓設計師、工程師和 AI 都知道現在該依照哪一套規則工作。只要大家看的來源不一致，設計系統就算存在，也很難真的被使用。

這也改變了我對規格的看法。當 AI 成為交付流程的一部分，規格就不能只靠人的默契理解，而是要清楚到可以被執行：顏色要從 token 來、元件狀態要完整、每次變更都要能被檢查。規則寫得越清楚，人和 AI 就越能穩定協作。

我也意識到，AI 的價值不只是幫我們更快完成原本的工作，而是讓我們重新檢查：哪些工作其實只是舊流程留下來的中間步驟。當這些步驟被省掉，設計系統就不能只是文件，而要變成設計、工程和 AI 都能共同使用的工作基礎。

最後我學到，好的治理不是把所有摩擦都消除，而是把需要人判斷的地方留下來。例如「merge 不等於上線」就是一個刻意保留的安全節點：可以自動檢查的事情交給系統，不可逆的發版決策留給人。這讓設計系統不只是元件集合，而是一套支撐團隊安全交付的工作方式。

下一步，我希望設計系統能承載更多設計判斷，例如間距節奏、無障礙規則、內容語氣。讓它不只說明「畫面長什麼樣」，也能保存「為什麼這樣設計」。