一人設計師的 UI/UX 設計工作流程
本篇分享我在新創或中小型團隊中，作為唯一設計師所參與的 UI/UX 設計工作流程。每間公司做法不同，這只是我個人的實務經驗，僅供參考。
團隊組成與角色分工
我遇到的團隊結構大概會是：PM 3～4 位、前端 2～4 位、後端 3～5 位、設計師 1 人。
而我通常就是那個一人設計師，負責：
- Wireframe（流程圖／畫面結構）
- UI 設計稿
- Prototype（互動原型）
- Design QA（設計驗收）
- 設計系統維護
早期用過 Sketch＋Zeplin，現在則全都切換到 Figma。有時候要呈現複雜的動態效果，我也會用 After Effects 做成動畫來展示。
Kick-off：專案啟動會議
專案一開始會有 Kick-off 會議，通常是由 PM 或需求方介紹專案背景與目標。整體專案的流程與時程規劃則由 PM 主導。
不同公司 PM 用的工具五花八門，我遇過的有：
- 畫 wireframe 工具：Axure、Adobe XD、Figma
- 時程管理：Asana、Jira、Trello、Planner、ClickUp、GitHub
- 規格文件：Jira、Axure、Figma、GitHub
工具差異不大，對我來說只要時程規劃裡有甘特圖就很加分，容易看。
規格書內容與前期討論
規格文件一定會包含 user story，其他內容則因 PM 的風格與專案規模而異。有的 PM 會詳細到附上 flow chart 和 wireframe，有的則只會寫一堆文字，甚至完全不畫畫面，規格書裡也會定義好 API 需求。
時程方面，我的經驗是大家都憑經驗感覺抓，抓得挺隨性，我動作算快，我說多少時間就多少時間通常大家也都沒什麼意見，我會提早蠻多完成預留討論修改時間。
但有遇過需求方亂給大家壓時間，例如：需要兩週的，被壓三天，這種亂壓的沒有一次有正常運作，多來幾次就沒人相信了。反正就職場鬼故事，哈哈
Wireframe 設計流程
拿到需求後，我會先抓出流程上的大問題與PM討論，如果改動幅度大會先跟需求方確認方向。
我會在 Figma 製作高擬真的 wireframe，整份畫完再集中討論，畫面用黑白色（使用 Figma 的 blend mode：luminosity），避免讓人誤會這是已完稿的設計稿。這個階段主要是釐清邏輯流程，不是討論視覺樣式。
我是用 Figma 的 Auto Flow plugin 製作流程線。但缺點是上限只能拉 50 條流程線，小技巧是「剪下再貼上」線條數量會重新計計算，但會失去同步功能。
設計確認與提前偷跑
Wireframe 初版畫好後，會跟需求方、 PM、工程師們再開一次會確認。
通常在這個時候，我已經開始偷偷進行 UI 設計稿了。因為有時候 wireframe 階段卡太久，而很多問題只是小地方，例如文案或邏輯確認，實際上大致架構已經定案。
這階段也會與工程師確認是否有元件可以重用、API 是否需要微調等，討論期往往比預期更久，可能是需求方在糾結文案或是進到高擬真階段，發現跟想像的不一樣。
UI 設計稿階段
UI 設計稿這邊我會沿用 wireframe 架構，搭配設計系統，如果不是全新頁面基本上產出速度會很快。
設計與 PM 討論時，如果我有更好的互動方式或視覺想法，我會主動提出。我的經驗是不要把希望放在下一版再優化，因為下一版可能遙遙無期。想到什麼好點子做，當下就得做。
有遇過PM 堅持要調整基礎元件樣式的(要調整到設計系統的)，我通常就會阻擋了，阻擋不了就會開會請需求方決定，目前的經驗是大家還是會希望能遵守就遵守，畢竟工程師要改也煩，因為我的立場就是要遵守設計系統。
設計稿與PM達成共識後，會再與參與專案人員再開一次會，再確認有無要調，要調再改，因為這份未定案的設計稿工程師也看得到，但還不是完稿，我會在會議中提醒至少三次，這還不是交付稿，工程可以偷跑，但後續有改的話不能抱怨，這要強調不然有些工程師會抱怨一直改。
設計交付與版本控管
設計稿完成後，會再開一次設計交付會議，在 Figma 中，我會儲存版本記錄，例如 功能名稱 v1.0，PM 會將此 URL 貼入規格書供開發查閱。
這個會議會跟工程師告知設計稿的檔案流程位置在哪邊，避免工程師看錯份檔案，確保看到的是最新版本。
在開發的途中，也會有各種原因讓規格變動導致設計稿也需要調整，可能是需求變動、需求方看到開發到一半的畫面有別的想法，流程UI狀態有漏、文案調整、改好後就調整設計稿的版號說明，並於顯眼處標記調整處。
設計 QA 驗收流程
這時候若出現「怎麼長這樣？不好用？」的抱怨，但其實是因為很多地方跟設計稿不一樣，如果只有一兩個地方，PM或是需求方還可能說的出來，如果是很多地方的話，通常就講不出來了，只會說很怪但說不出來，我的做法就是把開發完成的畫面截圖，跟設計稿比對，把所有不一樣的地方圈出來，一個一個標注如何調整，標註完一批就送出去請工程師調整，通常會調整兩到三次，比較難一次就把所有問題圈出來，就像整理桌面，要先清掃桌面的垃圾，才有辦法知道桌面有無髒污，比較大的問題先抓出來，才有辦法發現比較小的問題。
這階段我會特別認真處理，因為下次要調整也不知道會是何時了。後續功能測試驗收有 QA 的公司會有專人測試，沒有 QA 的公司則由 PM 自行測試。
專案結束，迎接新專案
上線後客服會持續搜集回饋，會再視情況調整，等這個專案收尾、上線、測試完，下一個新專案也往往已經開始 kick off 了
在實務經驗，有些流程真的會跳過
網路上可能會看到各種完整的產品專案開發流程，非常仔細，但我的實務經驗是每個專案都很趕，很多流程常常都跳過沒做，像是用戶訪談、persona、prototype，但我的意思並不是指那些流程不好沒必要，我也認為所有流程都確實走過，可以大大提高做好產品的機率，但現實面就是趕趕趕，這個專案做完趕下個專案。
