🌏 Read this article in English
PM 丟了一張 Figma 連結到 Slack。
「先定這個。」
工程師盯著螢幕，游標停在第 1 行。
這次該先畫 Figma？
還是先寫 Swagger？
還是…直接開 IDE？
看似選 Design-First 最安全，對吧？
不一定。如果這個 API 要給第三方開發者用，第三方平臺通常需要先有 API contract——Design-First 反而會繞遠路。
這三個選項，本質上都在解決不同維度的問題。起點若不符合情境，後期重構成本可能上升。
三種方法論各自解決什麼
團隊裡常發生這種對話。
PM：「這個功能先畫個 Wireframe 給我看看？」
工程師：「規格還沒定，單靠畫面還不足以支撐 API contract。」
老闆：「別吵了，先出個 MVP 驗證市場反應。」
聽起來很合理，對吧？
但問題是：「API contract」對工程師來說，是前後端對齊的契約；對 PM 來說，那只是看不懂的 JSON。
我們先釐清限制。
方法 A：Design-First（Figma 先行）
流程：需求 → Figma 設計 → 確認需求 → 開發 → API
優點：利害關係人「看得懂」。他們不需要讀 JSON，只需要點點頭。
代價：可能設計出難以實作的東西。
方法 B：API-First（規格先行）
流程：需求 → API contract → 前後端並行 → 整合驗證
優點：技術基礎穩固、前後端可並行。
代價：抽象。利害關係人看不懂。容易脫離使用者需求。
方法 C：Code-First（迭代先行）
流程：MVP → 驗證 → 迭代 → 迭代…
優點：快速驗證、可工作軟體優先。
代價：技術債累積、重構成本高。
為什麼 Design-First 是推薦的起點？
在大型企業系統整合、多團隊並行開發的情境下，API-First 是標準作業程式。
但問題是：大多數新產品、新功能的起點，不是「系統整合」，而是「價值驗證」。
1. 產品是給「人」用的
看得到的東西 > 抽象規格。
PM 看 Figma，能說：「這個按鈕位置不對。」
PM 看 JSON，只能說：「這個欄位格式有問題。」
這兩者的溝通成本，差了不只一個數量級。
具體來說，PM 可以審 domain semantics（領域語意）。文字規格、測試用例也能降低猜測，僅 UI-heavy 場景特別依賴設計圖。
2. 需求變更成本
改 Figma：30 分鐘。
改代碼：3 天。
這不是時間差，是腦力開銷。每次切回去，都要重新啟動大腦的開機時間。
3. 團隊對齊
PM、老闆、客戶都看得懂 Figma。當所有人對齊在同一張圖上，決策速度會變快。
4. AI 時代的優勢
有設計圖 → Claude/Stitch 有參考依據。
若缺少驗收準則與設計約束，AI 輸出一致性會下降。
AI 工具是放大器。如果你連需求是什麼都說不清楚，AI 只會幫你更快地放大需求不清造成的返工。
Design-First 的四個常見風險
Design-First 不是萬靈丹，它有四種常見的風險。
風險 1：設計脫離技術現實
設計可能超出目前技術、成本或時程約束。
比如：設計師畫了一個無限滾動的清單，但後端資料庫沒有 cursor-based pagination 的支援，重構成本極高。
緩解方式：開發早期參與設計 Review。這不是讓工程師來「否定」設計，而是讓工程師在設計階段就補充技術約束。
風險 2：工具輸出不一致
Stitch 每次生成結果不同。
緩解方式：建立 Design System 組件庫。沒有 Design System 的 Design-First，元件差異、狀態遺漏與視覺規格漂移會讓你頭痛。
風險 3：設計 ↔︎ 代碼 gap
設計與實作永遠有落差。
緩解方式：接受並管理這個 gap。
風險 4：過度設計
設計太多用不到的功能。
緩解方式：先設計 MVP scope。
你的責任是『讓它變好一點』，不是『讓它完美』。
設計太多，等於什麼都沒設計。
取捨討論：沒有銀彈
Design-First 適合：新產品、MVP 驗證、有明確 UI 需求。
API-First 適合：大型企業系統整合、純 backend 服務。
Code-First 適合：技術探索、POC。
成熟方法 vs 新興方法，往往是 A 和 B 接力。我推薦「混合策略」。
混合策略：實務建議
前陣子，團隊裡發生了一件事。
有個 Junior 用 AI 寫了一個功能。大概 500 行，花了兩小時。效率很高，他自己也很滿意。
我們的 Senior 花了十分鐘 review，然後皺著眉頭說：
「這邊邏輯還有可優化的地方。而且你沒考慮到，如果這個 API 要給外部用，你的 Error Code 定義太隨意。外部客戶接到第三天就會打電話來罵。」
Junior 愣了一下：「但 PM 只給了 Figma…」
Senior 說：「Figma 是給使用者看的。API 是給開發者看的。兩者都要顧。」
這就是為什麼我們需要混合策略。
階段 1：Design-First（需求確認）
- 設計師畫 Wireframe/Mockup
- 利害關係人 Review
- 開發參與，標記技術風險
階段 2：API-First（技術規劃）
- 根據設計定義 API 規格
- 前後端對齊契約
- 並行開發
階段 3：Code-First（實作迭代）
- 快速實作 MVP
- 驗證後迭代
- 持續重構
這不是理論，是實務教訓。
怎麼跟老闆說？
「老闆，我先用 Design-First 跑兩週做 MVP。出問題我負責。如果驗證成功，再切入 API-First 做規模化。」
這句話讓主管知道：你不是在吵架，你是在控管風險。
結語：這個問題真的值得做嗎？
工具是放大器，但起點決定放大的是價值還是負債。
在產品階段尚未穩定時，起點選擇會影響後續溝通與返工成本。
你不用現在就有答案。但開始想這個問題，就是第一步。
起點與情境匹配，比工具本身更重要。
下一個功能的起點，你會從哪裡開始？
是花在畫圖、寫規格，還是…先確認這個問題真的值得做？