期間｜
2025.07 – 2025.10
角色｜
UIUX 設計師（設計系統、流程與規格）
備註｜
因應保密條款，所有圖片皆以抽象示意
貢獻｜
本專案的核心貢獻在於設計基礎建設的重建。透過設計系統重構、規格文件化與流程標準化，建立一套能被工程團隊長期維護與實作的設計運作方式。
問題背景
我接手的不單是設計問題，還是一個需要重新梳理規格脈絡的系統整合專案
WebPAM 是一個整合公司既有產品的新系統，目標是在現有功能與操作邏輯的基礎上，將不同產品逐步整合至同一個平台。由於專案仍處於初期階段，因此多數功能其實都是源自於舊有系統。
在實際參與專案後，我發現除了介面設計本身外，還存在一些更底層、同時會影響設計與開發的問題。如果這些問題沒有預先解決，之後的設計與開發都會很難真正落實。
1
缺乏唯一且可依循的規格文件
本專案在進入設計與開發階段時，並沒有一份能清楚說明舊系統規格與行為邏輯的文件。因此，如果團隊想要理解產品行為與規格，只能透過實際操作舊系統，或閱讀現有的程式碼來推論。
這樣的方式不僅效率不佳，也容易讓團隊中不同成員對同一個功能產生理解落差。
2
設計系統引用混亂，設計細節未與前端對齊
在現有的 Figma 檔案中，同時存在多個版本的設計系統與大量的 Local 元件。設計系統的引用來源不一致，元件命名與狀態定義也沒有一個統一的規則，導致設計稿本身非常難以維護。
這同時會引響到開發階段，工程師沒辦法單靠設計稿完成實作，需要反覆對照元件庫，或尋找過去類似的元件來想辦法實現。
3
設計產出以靜態頁面為主，缺乏頁面之間的關聯
設計產出主要以靜態畫面為主，幾乎沒有描述流程、狀態或頁面之間的關係。這讓工程師在理解整體操作脈絡時，需要花費大量的時間反覆測試舊系統，或透過程式碼追溯行為，才能確認功能細節與邊界條件。
這不只增加了實作成本，也讓設計決策與實際產品之間無法準確落實。
在這樣的情境下，如果我繼續沿用原本的設計交付方式，其實很難完整且清楚的將系統呈現給工程團隊。因此，我選擇先補齊設計系統、流程定義與規格文件，作為後續設計與開發能夠順利推進的基礎。
重建設計系統
透過設計系統重構，建立能與工程開發對齊的設計語言
在釐清專案的整體狀況後，我很快意識到，如果沒有一套穩定、達成共識的設計系統，後續不管是流程設計還是規格整理，都只會持續在不穩定的基礎上增加複雜度。
當時的 Figma 檔案中，同時存在多個版本的設計系統，以及大量以 Local Component 形式存在的元件。這樣的狀態，使設計稿在實際使用時，很難判斷哪些元件是目前的標準做法，也無法確保不同頁面之間的設計細節具有一致性。
此外，由於公司採用的是基於 Vuetify 的第三方設計系統（Materio），設計系統本身其實已經對應到一套實際可用的程式碼。然而，當時設計端的元件命名、設計 token 與狀態定義，並沒有完全對齊工程實作邏輯，導致設計稿與實際開發之間難以達到完全一致。
於是，我選擇先花時間理解 Materio 在程式碼層面的設計邏輯，包含 Design token 的應用、色彩與透明度、元件命名方式等，並與前端工程師討論命名與使用上的共識。接著，重新梳理並重構整個設計系統，讓設計端使用的所有元素，都能夠直接對應到工程實作。
同時，我也依循產品的側邊導覽與功能層級，重新整理 Figma 檔案與 Page 結構，方便工程師瀏覽設計稿。同時，我也隨著專案的推進，逐步重構設計稿，確保所有元件皆引用自新的設計系統，達到 100% 的引用率。
對我來說，這次的設計系統重構，不只是整理元件或調整樣式，而是讓設計真正成為工程可以信任並依循的語言，為後續的流程定義與規格整理，先打好穩定的基礎。
標準化設計交付
將設計交付標準化，讓流程、狀態與互動不再依賴口頭溝通
在檢視現有的設計稿時，我注意到過去的設計交付大多以靜態畫面（Mockup）的形式提供給開發團隊。然而，我很快就判斷，這樣的交付方式沒辦法完整說明整個系統的操作行為。
在缺乏流程與狀態說明的情況下，工程師必須自行推測使用流程，再回頭對照舊系統，確認每一個操作背後實際對應的行為後，才能開始開發。這樣的方式不僅耗時，也讓設計稿本身無法成為一個可靠的實作依據。
因此，我沒有沿用既有的交付方式，而是直接決定調整設計呈現的重心，讓設計文件本身就能說清楚「流程如何發生」、「狀態如何轉換」，以及「在不同條件下系統會如何回應」。
為了支援這樣的呈現方式，我先利用 Figma Community 中的資源，快速客製化了一套適用於公司內部的 Annotation Kit。這套工具包含了 Pointer、Section Header、Cursor、Note 等元件，專門用於標注流程、操作行為與補充說明。
接著，我將這套標註系統實際應用到設計稿中，透過繪製 UI Flow 清楚說明頁面之間的切換關係，並標註不同狀態下（如 Loading、Error、Empty）介面應呈現的內容。
這樣的調整，讓設計交付不再只是畫面參考，而是成為能協助工程師快速理解整體流程與系統行為的溝通工具。對我來說，這一步並不是後續的補救，而是在專案初期就必須先建立好的基礎工作
建立規格來源
以規格文件作為唯一正確來源，避免設計決策被程式碼反推
在流程與狀態逐步被說清楚之後，我很快又遇到另一個問題：即使設計稿已經能描述系統如何運作，但是還是缺乏一個地方，能把所有規格決策真正定下來。
當時，許多產品行為其實只存在於舊系統的實作或現有的程式碼中。當設計或開發上出現疑慮時，最直接的做法往往是請工程師去查 code，或直接在終端機跑既有指令，再依結果回推產品行為。對我來說這並不是一個健康、可延續工作流程。
我認為，規格應該是可以被清楚閱讀、討論與確認的內容，而不是只存在於程式碼裡，或仰賴個人經驗來解讀。如果設計決策需要靠閱讀底層實作才能理解，那麼設計與產品本身，其實潛藏著極大的不穩定因素。
為此，我開始建立一套 Spec Note，作為規格文件的集中記錄方式。這份文件不只是備註，而是用來明確記錄：
功能與狀態判斷的條件與邏輯
不同情境下系統應有的行為與回應
已在設計、工程之間對齊的產品決策
透過 Spec Note，設計、工程與產品之間，就可以有一個能共同查閱的參考依據。當規格需要調整時，也能清楚知道調整的是哪一個決策，而不是重新從程式碼中猜測系統原本「可能」是怎麼運作的。
對我而言，建立規格來源並不是為了增加文件數量，而是讓設計決策有一個明確的依據。這也讓設計能夠從被動回應實作結果，轉變為主動參與產品規格定義的一環。
成果反思
這次經驗重新定義了我對工程型產品中「設計角色」的理解
透過這次 WebPAM 專案，我更加確定，在高度複雜且工程導向的產品中，設計的價值並不只存在於畫面品質，而是在於是否能建立一套能被長期使用、並真正支援開發的工作基礎。
當設計系統、交付方式與規格文件被逐步建立後，設計不再只是單向輸出畫面，而開始成為設計、工程與產品之間的共同語言。設計決策能被清楚說明、檢視與討論，也減少了過去仰賴個人經驗或反覆口頭確認的情況。
在實際合作過程中，工程團隊也明確回饋，這樣的設計交付方式讓他們在理解流程、狀態與規格時，花費更少時間與心力。設計稿不再只是參考畫面，而是能協助他們更快判斷實作方向、減少反覆測試與來回確認的依據。
這次經驗也讓我更加確信，設計師應該主動參與產品規格的定義，確保使用體驗是被有意識地設計，而不是在實作過程中被動形成。
