優化產品設計更迭工作流，重塑 Figma 文件架構，提升效率的關鍵方法與實例
前言 — 產品設計更迭維護好頭痛 😫
在縱向敏捷團隊，橫向產品設計團隊的十字工作流中，產品設計文件更迭這樣的議題，看似凌駕於團隊溝通與運作之下，實則是一門打地基的重要環節，身為一名產品設計師，一定會遇到以下這些問題
對團隊的 Stakeholders 來說：
- 無法確定產品設計文件的最新版本
對產品設計團隊來說：
- 時常需要回覆 Stakeholders 最新版本在哪裡
- 每一次的更迭設計總是耗費許多時間，老是掉東掉西
- 難以查找或遺忘設計時的規劃梳理脈絡
接下來會分為三大部分分享
- 如何在團隊內以 User Journey map 梳理工作流的推動過程
- 如何制定產品總體圖（Product Index）與文件更迭交付（Branching in Figma）打好基底
- 除了基本的 Design System，如何透過建立關鍵頁面（Key Page Components）幫助更迭效率
本文架構
- 前言：產品設計更迭維護好頭痛
- 梳理現況，找到關鍵問題
- 制定文件更迭交付的全新工作流
- 沒有絕對相同的問題與答案，記得隨時回顧與更迭
- 結語梳理現況，找到關鍵問題
1. 以 User Journey Map 梳理工作流
有邏輯的找出問題是一件很必要的事情，以 User Journey Map 嘗試把自己當作 User，盤點出從「接手專案」一直到「文件交付」、「產品上線」的整個過程，就可以舉列出不少 Pros & Cons，也比較能幫助設計團隊與自己把問題拆解開來檢視。
過去的時空背景，先前的 Workflow 有許多不方便，包含：
- Figma 尚未推出 Dev Mode，還是以 Figma 進行設計，Zeplin 交付開發
- 設計團隊當時區分 UX 及 UI Designer ，有大幅度前後棒接手文件的情況，並非 End to End 的 Product Designer 架構
- 團隊還在瀑布流，並非跑 Scrum
如今新的時空背景有許多改變，能夠清楚釐清出哪些問題是能優化的！
2. 拉起溝通，收整其餘需求與問題
由上圖可見，在整個流程的梳裡過程中，我都會附上實際運作過程中的截圖，原因是設計文件的更迭橫跨著不同職能線，在過程中也同樣會盤點到主管、PM、RD 的痛點，帶著這份文件與他們一起討論解法或是搜集更多問題的時候，更能幫助團隊保持同樣認知。
3. 針對關鍵問題定義出可能的解法
最後收整下來我發現除了新的時空背景可能能解決的軟體間更迭問題以外，最核心的就是包括本文前言所提到的核心問題，我也與設計師們一起思考並簡單寫下了對應的可能解法。
制定文件更迭交付的全新工作流
1. 產品總體圖（Product Index）
首先不可或缺的就是產品的架構圖，重新為產品好好的區分功能與模塊，它像是一個地圖，為團隊成員提供索引，可以解決老是有不同成員問「哪個功能要看哪份檔案」地重複問題，這個過程至關重要的就是與 PM 達成共識，因為索引也能於 PRD 相關工具上制定（e.g. Jira confluence）未必採用 Figma，這就端看每間公司團隊間的運行方式而定，我們主要考量團隊 Scrum 更迭快速為主，PRD 與 Design Spec 共同於 Figma 維護。
2. 歸檔架構（Branching in Figma）
在新的時空背景下，Figma 業務端主動聯繫，經過一連串溝通，讓公司的 Figma 方案升級為 Organization Plan 除了多出了 ”Team” 的架構也加購了 Dev Accounts 以外，也能夠開始使用 Branching ，我也開始為這個新變化制定新的工作流並進行實驗，在此不贅述 Branching 功能，大家可透過其餘文章了解具體細節。
我認為值得分享給大家的幾個實戰 Key Points，包含：
- 以每個 Srpint（2 週）作為分支
因團隊縱向分成三個 Squad 跑 Scrum，而橫向設計成員們多，且偶爾會需要相互支援，在每個 Sprint 內會有密集的變動，所以我們並非以「產品功能」作為分支，當 Sprint 結束，就會由該 Squad 的設計師進行 Merge。
- 搭配 Section 功能來讓 RD、QA 知道每一次的更迭範圍
過程中因為主檔保持著全數最新的樣貌，會碰到 RD、QA 不大確定本次 Sprint 變動了哪裡的情況，不管使用 Section 還是高度彈性的溝通，這都不會是這個大問題。
- 收整所有設計脈絡的梳理
在產品設計職能裡，更加重要的是我們「以體驗角度」參與著最前段的功能與服務梳理，並提出交互的概念想法，這些梳理文字脈絡及概念都值得被留下，在後續產品更迭能夠回溯，不同於功能模塊檔是以 Sprint 作為分支，而是採以「功能服務」作為分支，當該 Sprint 梳理與概念提案結束後，同樣會由該 Squad 的設計師進行 Merge。
3. 關鍵頁面（Key Page components）
這個環節也是我認為各位可以參考的維護方式，除了目前最基本以一個 Figma 檔制定一份 Design System 收整著所有 UI Components 以外，在每個功能模塊檔內，也能建立 Key Page Components，並以這些 Key Page Components 去撰寫設計流程與定義，而不同的功能模塊若用到相同的頁面則能夠跨功能模塊的檔案，也表示未來若某一個頁面要做設計更迭，只需要更改該 Key Page Components 即可，不用盤點也不怕漏改。
嶄新的 Workflow 誕生
與設計成員們及 Stakeholders 整體對過後，不忘把這份 Workflow 留存，在未來加入團隊的設計師們都可以知曉目前團隊如何運作！
結語
團隊目前也已按照上述方式運行了近三個月，以上不同維度與顆粒的問題也成功被解決了，從中也會發現，原先制定的細節其實有部分就在後續高度彈性的溝通下，不一定需要去遵從或使用（e.g. 就算不使用 Section，只要團隊內說明也能夠清楚知道開發範圍），所以千萬不要馬上把能夠用溝通來解決的問題流程化，就算流程化也要謹記這些都是可「變動」且「彈性」的！
導入前與制定中的過程，也可以先思考：
- 對於當前的團隊背景及目標來說，這真的是個問題嗎？
會有上述的制定，也是因應新產品以及團隊架構改變的背景，別忘了與當前團隊成員討論目標，或是先確定當前工作流是否真的有很多痛點存在。
- 不仰賴軟體服務的情況下，還有其他解法嗎？
這點是我目前的主管 Travis 在過程中提醒的，所以後續我也同時提出了另一版採用 Version History 來記錄更迭的備案。
「若有一天公司不打算再續訂 Organization Plan，那是否有其他備案呢？」
最後希望這篇文章有成功幫助到大家，拍拍手與 Follow 我的 Medium 佛心隨性，我會不定期分享許多實戰型經驗！ :)
