期間｜
2023.12 – 2025.02
角色｜
UIUX 設計師（設計結構梳理、規格整理與設計資產管理）
備註｜
因應保密條款，所有圖片皆以抽象示意
貢獻｜
本專案的核心貢獻在於，在長期演進、缺乏統一結構的老系統中，逐步梳理設計資產與產品規格，建立一套能被團隊理解、查找，並持續沿用的設計工作基礎。
問題背景
在長期演進、缺乏結構的老系統中開始設計工作
Agentflow 是一個擁有約 25 年歷史的 ERP 系統，隨著時間不斷演進，功能持續累積，逐漸演變成高複雜度的系統結構。我接手時，前一位設計師已完成介面風格的初步翻新，並進行過公司內部工程師（同時也是產品使用者）的痛點訪談，為後續設計提供了重要的背景理解。
然而，在實際參與專案後，我發現真正影響設計與協作效率的，並不只是在畫面是否現代化，而是以下幾個更底層的問題。
1
缺乏清楚的系統目錄
與 Agentflow 相關的 Figma 設計檔案多達 18 個，檔案結構與命名方式不一致。雖然前人有嘗試建立目錄，但因為缺乏對應功能的說明，實際查找特定功能模組或畫面時，還是需要花費大量時間翻找。
這導致設計資產的使用高度依賴個人記憶，而非一套可被查找與理解的結構。
2
產品規格分散且高度隱性
由於積年累月的功能疊加，Agentflow 這個系統的功能層級深、模組多，且產品規格並未被完整文件化，而是分散在現有系統畫面、教學影片，甚至工程師的口頭說明中。設計工作往往需要先花時間「拼湊理解」，才能進行實際的設計判斷。
在缺乏統一規格來源的情況下，設計與開發沒有一個共識，造成溝通與修正成本增加。
3
設計資產缺乏一致的使用規則
由於設計系統缺乏明確的命名與結構規範，即使團隊中的三位設計師（包含我）都有 Figma 的基礎，實際產出還是很長出現狀態不一致、元件設定不同步等問題，這進一步影響設計稿在切換狀態時的穩定性。
些問題並非單一畫面可以解決，而是會隨著專案時間的拉長，不斷被放大的系統性風險。
在這樣的背景下，我逐漸意識到，如果直接延續現在的設計方式，只會讓設計與產品知識持續累積在混亂之中。因此，我選擇先從建立結構、降低理解成本開始，作為後續設計與協作能夠推進的基礎。
建構檔案目錄
先讓整個系統能被看懂、被理解，設計才有可能開始
在釐清專案背景後，我很快意識到，當設計資產本身難以查找與理解時，不論設計交付文件有多完整，都會因為協作成本太高導致設計與開發效率低下。
因此，我沒有急著繪製介面和優化流程，而是先從「讓設計資產能被理解」這件事開始。
我重新建立了一套以功能為核心的稿件目錄，將 Agentflow 中的所有功能逐一列出，而不是僅以檔名或畫面分類。同時，我也為每一個功能標註目前的狀態，例如是新增功能、刪除功能、流程優化，或僅是命名調整，讓團隊能快速掌握系統的變動脈絡。
同時，我夜在目錄附上對應的 Figma 檔案連結，並細分到檔案內的 Page 層級。由於每個 Page 通常對應一組功能模組，這樣的結構讓設計師與工程師可以直接跳轉到所需內容，也減少在大型檔案中等待載入與反覆翻找的時間。
這樣的調整，讓願意查閱目錄的工程師能更快找到設計稿，實際詢問檔案位置的情況也明顯下降。對我來說，這份目錄不只是檔案清單，還是一個能幫助團隊理解產品架構的文件。對後續的規格整理與設計決策打下堅實的基礎。
產品規格文件化
當產品規格只存在於人的記憶與經驗中，設計就無法真正對齊
在整理完系統目錄後，我很快意識到另一個更棘手的問題：沒有一份產品規格文件。許多功能的行為與限制，並不存在於任何正式文件中，而是分散在工程師的記憶、過去的實作經驗，或是零散的討論紀錄裡。對設計來說，這代表每一次畫稿，都必須不斷向工程確認「實際會怎麼做」；對工程而言，則需要反覆從舊系統或程式碼中推敲規格，才能確定是否符合既有邏輯。
在這樣的狀態下，設計很容易被迫成為「畫面翻譯者」，而不是能夠參與產品決策的角色。 因此，我選擇建立一份以功能層級為核心的規格表，作為設計與工程之間的共同參考基礎。這份規格表不以畫面或頁面為單位，而是將系統中的功能依照層級逐步拆解，從模組、功能，到更細部的操作與輸入項目，全部以結構化的方式整理出來。
同時，我也在規格表中標註每一項功能目前所處的狀態，例如是新增功能、流程優化、命名調整，或是即將被移除的項目。這讓團隊在討論時，不只是在確認「怎麼做」，也能快速理解「為什麼現在需要調整這個功能」。
透過這樣的整理，原本隱藏在系統與程式碼中的產品規格，首次被明確地攤開來討論。設計不再需要從實作反推規格，工程也不必依賴個人經驗補齊脈絡，而是能以同一份結構化文件作為決策與溝通的基礎。
統一設計規範
當設計系統沒有規範，隱性問題會不斷累積，造成系統不穩定性
當時的設計系統並沒有明確的命名規則與結構規範，同一類元件在不同檔案中，可能有不同的命名方式、屬性設定與狀態管理方式。即使團隊中的三位設計師（包含我）都具備 Figma 的基礎操作能力，實際協作時仍經常出現狀態不同步、切換 Variant 時樣式掉落等問題。
這類問題在短期內看似只是操作不順，但隨著專案時間拉長，會逐漸演變成影響整體設計穩定性的「設計債」。
因此，我選擇從元件層級重新建立一致的使用規則。我先盤點實際被頻繁使用、且最容易出現狀態錯誤的元件，並以「Tree Item」這個元件為切入點，重新建構其元件結構、命名方式與狀態定義，確保所有狀態都能在同一套元件邏輯下被正確切換與維護。
在這個過程中，我特別留意不同設計師實際使用元件的情境，避免設計系統只存在於「理想結構」，而是能夠支援真實的設計流程。當元件結構與命名被統一後，設計稿在切換狀態時的穩定性明顯提升，過去常見的樣式錯誤與設定遺漏，也大幅下降。
對我而言，這不只是一次元件重構，而是替團隊建立一套能長期運作的使用規則，讓設計系統真正成為協作的基礎，而不是額外的負擔。
成果與反思
在缺乏共識的系統中，重新定義設計的角色
在 Agentflow 這樣一個歷史悠久、功能深還缺乏共識的系統中，設計師的角色並不只是補齊畫面，而是先讓整個系統「變得可以被理解與維護」，因此當我補齊這些缺乏的元素後，獲得了以下的回饋：
1
「理解成本」下降
透過重新建立目錄結構、規格表與元件使用規則，團隊在查找檔案、理解功能位置與狀態定義上的時間明顯下降。設計在切換狀態與維護畫面時的穩定性也顯著提升。
2
設計產物變得可延續、拓展
這些產出並非為了當下的畫面需求，而是作為後續功能擴充與維護時的共同基礎。即使在需求持續變動的情況下，團隊仍能在既有結構上延伸，而不需要反覆重來。
3
設計成為可信任的參考依據
隨著結構與規則逐步被建立，設計稿不再只是視覺參考，而成為設計、工程與產品之間可以共同對齊與討論的依據，降低了對個人經驗與即時溝通的依賴。
回頭看這段時間的投入，我逐漸改變對「工程型產品中設計角色」的理解。也正是在這個專案中，我有了新的體悟：
1
我重新理解了「設計的起點」
這個專案讓我意識到，在高度複雜且缺乏共識的系統中，設計的起點並不在於介面或流程，而在於「理解」。如果系統無法被團隊看懂，再完整的設計交付也只會增加協作成本。
2
我認識到除了回應需求，設計師還要識別風險
許多問題在初期看似只是零散的不一致，但隨著專案時間拉長，會逐漸放大成難以維護的系統性風險。這個專案讓我相信，設計師的責任也在於主動辨識並處理長期風險。
3
我體會到「可維護性」在設計決策的扮演的重要角色
在 Flowring 專案中，我開始將可維護性、擴展性與一致性視為與畫面品質同等重要的設計指標。這也影響了我後續在功能拆解、元件設計與文件整理上的決策方式。
