設計師自己送 PR：Figma Make 讓卡在 backlog 的小修正一天上線
把 production code 接進 Figma Make，設計師自己把卡在 backlog 的無障礙小修正一路做到合併 PR——中間不用開任何一張票。
把一個對比不足的日期選擇器改好、把螢幕報讀器唸錯的標籤修對——這種小事你知道該做，但它太瑣碎，排不進工程師的優先序，於是寫成一張票丟進 backlog，然後被後面接連上線的功能一層層埋掉。Figma 把這段最容易被犧牲的「最後 20%」重新設計了一次。
這篇 Workflow Lab 示範一件事：當設計師把公司的 production code 直接接進 Figma Make，那些卡在 backlog 的小修正，可以由設計師自己一路做到合併的 pull request——中間不用開任何一張票。對正在學 Figma、想搞懂 design-to-code 到底怎麼串起來的人，這是一個很具體的範例。
從設計到程式碼的交付，傳統上像一條單行道：設計師把想法寫成規格，交給工程師實作。大型、定義清楚的功能這樣跑很順。麻煩的是那些讓體驗真正完整的細節——對比不足的日期選擇器、報讀器唸錯的標籤、藏太深的行動呼籲。每一個都太小、排不進優先序，卻又太重要、不能直接丟掉，於是它們就懸在 backlog 裡慢慢腐爛。這「最後 20%」，正是一個「技術上能動」的網站和一個「真的好用」的網站之間的差別。
還有第二層成本。當設計師用文字把改動描述出來、再交給別人，細節會在轉譯途中流失。「間距再緊一點」或「這裡報讀器唸錯了」變成一來一回的截圖和確認，工程師被迫去翻譯一個設計師其實可以自己下的決定。
範例主角是一間虛構的美術館：Museum of Speculative Futures（MOSF），主題是「文化如何想像未來」。他們正在做一次完整的架構重寫，同時想補強網站的無障礙。資源是最大的難題——設計師想處理無障礙缺口，工程師卻得專心把重寫做完。
PM 想了另一條路：重活留給工程師，那些低成本、講究手感的小改動，交給設計師用 Figma Make 搭配 production code 從頭到尾自己收尾。畢竟「最後 20%」正是一個技術上能跑的網站，和一個真正人人可用的網站之間的分水嶺，於是團隊就這麼定案。
動手之前，設計師想先壓力測試現在的體驗。他用 Figma Design 裡的 agent 生出一組合成人物（synthetic personas）——第一次來規劃行程的訪客、回訪的會員、用螢幕報讀器操作的人——讓每一位各自走一遍網站、回報卡住的地方。
回來的意見很具體，而且大多很小：展覽頁一個令人困惑的標籤、一個容易被忽略的行動呼籲、一個一眼看不懂的日期選擇器、還有搜尋在查無結果時直接停在一片空白。單看每一項都不大，合起來卻是決定網站好不好用的細節。設計師把意見處理過一輪，再把改動帶回團隊，和工程師、PM 一起逐項做 gut check，確認每個改動都指向同一個目標：一個所有人、用各種方式上網都能順利瀏覽的網站。
這批改動小而且大家都懂，設計師決定不寫票、也不排隊等，直接向工程師要 codebase 的權限——目的很單純，就是親手把這幾個修正處理掉，重寫的重活照樣留給工程師。工程師開了權限，設計師把專案的 GitHub repo 接進 Make，從目前的網站開一條新分支，先挑清單上看起來最單純的一項下手：展覽頁那個被合成人物嫌難讀的日期選擇器。
在靜態 mock 裡，這是五分鐘的小改。可是一對著真的程式碼跑，Make 就浮出畫布看不見的東西：這個日期選擇器是一個共用元件，同一個也用在活動行事曆和會員註冊流程裡。看起來只是改一處，實際上是一個要同時在三個地方發生的改動。若走傳統的票，很可能只修了展覽頁那一個，另外兩處就留在舊版，變成一個沒人會注意、直到很久以後才爆出來的不一致。因為設計師人在 code 裡，這個共用相依當下就看得見，修正也能一次改在對的地方。
視覺上的修正就位後，設計師把成果送給團隊做最後 review。無障礙的目標就在這一關被講清楚：每個改動該怎麼對輔助科技運作，全隊直接標在它所在的位置。包括——共用日期選擇器該報讀出來的 aria-label，讓它不只看得懂、也唸得對；一個和畫面文字一致的報讀器標籤；一個會確實走到行動呼籲、不會從旁邊跳過的 focus order；還有一個帶著訊息的空狀態，讓「查無結果」的搜尋不再是一片沉默。PM 確認這些都還扣著無障礙目標，工程師補上哪些要在 code 端處理，設計師把最後的細節收進去。
處理完最後一批標註，設計師直接從 Make 推出一個 pull request。工程師 review 這份 PR——此時更新後的設計意圖、團隊的留言、無障礙標註，全都掛在同一次變更上——批准、合併分支。原本會在 backlog 躺一季的修正，一天就上線了。更值得的是那份紀錄：一張票關掉就消失，裡面的決策也跟著蒸發；一次合併的變更卻把它們留下——留言、無障礙標註、把日期選擇器設成共用的理由。半年後有人再回頭看這個元件，走到今天這一步的來龍去脈，就攤在團隊的共同歷史裡。
傳統交付把設計師和工程師當成生產線上的兩個工站，這對大型、定義清楚的功能很有效。但那些收尾的細活、無障礙的改善、決定整體質感的打磨，需要另一種交付——一種設計師直接在 code 裡工作的交付。
這種做法不要求設計師變成工程師，也不要求工程師變成設計師。它讓兩邊各自把判斷力用在最該用的地方：工程師守著架構重寫，設計師端到端負責細節收尾，PM 讓整個專案對準目標。這條分支載著每個人的貢獻——看得見的設計、寫下來的意見、報讀器將唸出來的標籤——從畫布一路送到一個合併的 PR。原本會被砍掉的最後 20%，這次上線了。