摘要
Figma 在 Workflow Lab 中以虛構博物館 MOSF 示範一條產品修正路徑；這是官方教學情境，不是已證明成效的真實客戶案例。設計師先在畫布整理可用性問題，接著讓 Figma Make 連接 codebase（產品的程式碼專案），直接處理範圍明確的小改動，最後以 Pull Request（請團隊審查並合併程式變更的提案，簡稱 PR）交給工程師 review。
這不是要設計師取代工程師，而是重新分配那些重要、卻經常被 backlog 擱置的「最後 20%」。真正需要討論的，是哪些修正適合由設計師一路做到 PR，以及團隊要用什麼機制守住品質。
為什麼小修正常常永遠排不到？
產品裡最影響質感的問題，經常不是大型功能，而是模糊的導覽名稱、不夠醒目的行動按鈕、難以理解的日期選擇器，或沒有說明的空狀態。單看每一項都不大，放進工程 backlog（尚待處理的工作清單）後卻很容易被更急迫的需求往後推。
傳統流程還有另一個損耗：設計師以 ticket（工作項目）、截圖或文字描述細節，工程師再把描述翻成實作。當問題牽涉焦點順序、ARIA label（提供給螢幕閱讀器的介面名稱）或共用元件時，幾輪轉述就可能讓原本的設計判斷變薄。
這條流程實際怎麼走？
Figma 的案例先讓設計 agent 以不同 synthetic personas 檢視網站，再由設計師、PM 與工程師一起確認問題與範圍。官方也特別提醒，synthetic personas 只能協助提早看見明顯摩擦，不能取代真人研究。
範圍確認後，設計師連接專案 repository，從現有 codebase 建立 branch，再處理已知且低風險的修正。這一步的差異是：畫布上看似只改一個日期選擇器，進入程式後才會發現它其實是三個流程共用的元件，因此必須一起檢查影響。
完成可見介面後，團隊再補上螢幕閱讀器標籤、焦點順序與空狀態訊息等無障礙細節，最後由設計師發出 PR、工程師 review。PR 因而不只是程式差異，也保留了批註、討論與做出變更的理由。
- 先由設計、產品與工程共同確認目標與修改邊界。
- 使用獨立 branch，檢查共用元件與其他流程是否一起受影響。
- 把無障礙行為寫進 review，而不是只驗收畫面。
- 由工程師負責程式品質、安全性與最終合併判斷。
設計師能做，不代表每一種改動都該做
適合這套流程的，是範圍小、行為清楚、容易回復，且不牽涉資料模型、權限、安全或核心架構的修正。若改動會影響付款、認證、商業規則或大量共用狀態，就不應因工具看起來簡單而跳過工程規劃。
團隊也需要明確的權限與 review 規則。誰能連接 production code、哪些檔案可以修改、測試由誰負責、何時必須停下來找工程師，這些都比「設計師會不會寫 code」更重要。
真正被改寫的是 handoff，而不是職稱
過去 handoff 常被理解成設計師交付、工程師實作。新的工作流更像雙向協作：設計師可以在實際產品狀態裡完成細節，工程師則把判斷放在架構、風險與 review，而不是代為翻譯每一個視覺決策。
這套方法是否值得採用，最後仍要看團隊能力與產品風險。它最有價值的地方，不是讓每位設計師都能送出 PR，而是讓那些原本會消失在 backlog 裡的設計細節，有一條可追蹤、可審查，也能真正上線的路徑。