我們如何在產品團隊中導入 Figma
不可能 2019 年在討論的話題，都快 2023 年有人還在講這個吧？！
要用 Figma 很容易，但是如何在開發時間多年的團隊中從不同軟體轉換，是一個截然不同的挑戰。目前大約轉換約 11 個月，與團隊邊開發、邊整理並把比過去更好用的新 Libary 建立好，也使用了幾個開發週期，想把導入團隊的經驗做個小紀錄。
加上近期參加了一些設計分享會，發現仍有許多產品設計師有類似的問題，所以久違的用文章的形式分享。
當然軟體的選擇並沒有標準答案，每個團隊有自己的習慣的流程。這是一篇寫給都快 2023 年了，想要但是還無法將 Figma 或是希望的流程帶入團隊的主管或設計師的小分享，你們並不孤單。
How it started
2019 年就一直心心念念，想把 Figma 導入團隊將設計協作工具由 Sketch 轉 Figma，但在 2021 年底 2022 年初才終於成功。
我知道對一個年輕的團隊來說算是很晚，晚到我去年面試其他產品設計師時，講到我們在用 Sketch 都會覺得自己是不是不太潮，真的很不好意思
雖然從兩年前我私下最常使用的 UI 設計工具就是 Figma，但帶入團隊也不是說換就換的事，相信很多上線已久、開發時間緊湊的團隊都會跟我們遇到相同的困難：
障礙 1 ：數量龐大的設計檔案
我們負責的產品已營運總共 3 年以上，三年多來幾乎 1–4 個禮拜就會發版一次上新功能的頻率，分功能總共有上百個 Sketch 檔案
雖然過去有將每個 Project 分功能整理到同個文件上的好習慣，真的省了很多功夫，但有經驗的人都知道 Sketch 檔案丟到 Figma ，元件跟細節都會有很多需要調整的狀況，讓你想問天問大地，我為什麼要做這個？
障礙 2：人力與說服團隊支持
早期想要轉換時，設計光是每個 sprint 的需求就忙得要命，沒有多餘的時間可以研究跟執行。
在快步調的開發節奏下，讓主管或老闆為何需要花時間去轉換平台、支付這筆預算，以及對不熟悉 Figma 的開發討論與教學，也是一個需要先事先規劃的時間成本。
障礙 3 : 多次迭代的功能與元件
但多次迭代之下，難免有遺漏或是需花額外的時間尋找原始檔、閱讀當年開發的文件來確認細節，非常地耗時。
除了上述的問題，相信每個團隊，都會遇到各種能說跟不能說的時間阻因。
What we do?
那麼話不多說，以下是我們做的準備跟流程：
1. 讓團隊與主管知道我們為何需要改變
如果你不知道自己為何需要改變，那確實在能維持效率的狀況下，你也許並不需要改變。
在產品團隊，所有的決定都應該要有理由，以及可供評估的數據。
我們的目標是成為一個更有效率、更好的團隊，而不只是轉換設計軟體這麼簡單。
在轉換前先嘗試與團隊分享目前的趨勢、與主管計算並比較所有一年需要支付的預算、時間成本，以及未來預估能帶來的優點，讓團隊知道度過一段轉換的陣痛期，會迎來更美好、方便的未來，就能得到大部分人的支持。
2. 轉換初期
直接開始第一個 Figma project
當然在人力、時間有限的狀況下，你應該先弄清楚整個產品的優先順序是什麼，以我們的產品來說，大部分的頁面都已經有固定的雛形，做新功能時會以當期開發的 task 優先，一面整理相關功能檔案與 component。
3. 開發團隊：對不熟悉 Figma 的夥伴做小教學
許多工程師、PM 過去不一定有接觸過 Figma ，或是接觸過但每個團隊的開發流程不盡相同，在開始使用前做一個簡單的教學與討論是非常必要的。
我的方法是在第一個專案之前，先用淺顯易動的簡報，與開發同事分享 Figma 頁面架構、如何操作，以及示範一次在平時開發時，可能會遇到的流程。並且直接分享檔案請大家嘗試用 figma 留言對話互動，這樣使用一開始遇到問題時就能直接 tag 設計師討論。
很謝謝當時工程師同事，也分享了他在使用時遇到的問題跟經驗，讓其他開發能更快上手！
4.設計團隊：擬定切確轉換的計畫跟時間
目標不設定時間，永遠不會有達成的那一天。
列出須完成大目標，再去向下設立每個功能或頁面時間截點。
例如我們初步至少需要整理出以下檔案：
1. Design Library
2. iOS App UI
3. Android App UI
4. Web UI
那每一項之下，又包含哪些架構、頁面跟功能分配，在整理該項功能頁面時，也會一併把內含的元件納入 Library 整理，逐步規劃每一項可能達成的時間。
對迭代快速、已有三歲的產品來說，重新整理元件庫是一項艱鉅的任務。
產品因為比起兩年前語系更多元，元件需要有更彈性的設計，多次迭代之下，我們經常會需要去比對平台線上的樣式、找回兩年前的需求稿確認當初的交互細節，也找到好多工程師要修的 UI bug （？)
好處是在這個轉換的後期，我們也進行 audit 將所有的顏色、字級、間距、按鈕狀態、Dialog等等做收斂跟評估，重新審視每個元件存在的必要性，最終得到一個最新、最整潔好閱讀的 Design Guideline！
5.不斷地聆聽與學習
使用這幾個月的過程中，我們仍然不斷地向工程師、PM 跟其他同事搜集 UI 文件的使用反饋，以及不斷地優化元件庫與合作流程，希望我們交付的設計檔案，能進化成 SS 模範等級的 UI 文件。
感謝團隊同事不斷地與我們討論，還有 UI Designer 同事，花了很多時間整理 Sketch 檔案，並且規劃了清楚的 UI files 列表、不厭其煩的一起還過去設計團隊留下的設計債。現在整個團隊用 Figma 已經如行雲流水，回想到去年還在請同事上傳 Sketch 檔案的我，就發自內心的好快樂啊！
不只是推動 Figma ，在已有既定開發模式的團隊中推動新事物，比起個人或是小團隊還要難上許多，但相信只要以團隊長遠的利益為出發點，並且疏理清楚：
1.為何要執行
2.要做哪些事情
3.設立明確時間點
4.不斷得聆聽跟改善
並讓大家看到改變會更好的藍圖，即便會經歷陣痛期，夥伴們也會願意一起加入並幫助我們推動計畫 ✨✨
