解錯問題的代價，比解不出問題更高——前者你還以為自己完成了。Problem Framing 是一套把模糊、隱含、甚至錯誤的問題陳述，轉化成清晰、有邊界、值得投入的問題定義的實踐。它不是需求文件，也不是用戶故事；它是那個更早、更重要的步驟：確認我們在對的問題上花力氣。
為何先 framing
工程師拿到一個需求時，最大的誘惑是直接跳到「怎麼做」。這個直覺在問題已被清楚定義時是對的——但大多數時候，需求描述的是「症狀」，不是問題本身。幾個常見場景：
- PM 說「讓登入體驗更好」→ 真正的問題可能是「找回密碼流程太長導致用戶放棄」
- 老闆說「我們需要一個 dashboard」→ 真正的需求可能是「每週被問一遍同一個數字，煩了」
- 用戶說「App 太慢」→ 問題可能只出在特定步驟，其餘地方根本不慢
這類偏差不需要惡意，只是自然發生的。人在描述問題時習慣用解法語言（「我需要 X」），而不是問題語言（「我正在碰到 Y，代價是 Z」）。Framing 的工作，是把解法語言翻譯回問題語言。
核心工具
5 Whys
源自 Toyota 生產系統（1970s），由大野耐一提出。做法簡單：針對一個問題症狀，連問五次「為什麼？」，每次用上一個答案繼續問，直到碰到一個可行動的根本原因。
範例：
症狀：「用戶在 App 留不住，Day 7 留存率 12%」 Why 1：為什麼用戶留不住？→ 他們在第一週就放棄了 Why 2：為什麼第一週就放棄？→ 他們不知道核心功能怎麼用 Why 3：為什麼不知道怎麼用？→ 新手引導只有三頁 tooltip，沒有實際操作 Why 4：為什麼引導這麼薄？→ 當初沒有優先排進 roadmap Why 5：為什麼沒有排進 roadmap？→ 當初假設用戶能「自己摸索」
根因：「自己摸索」的假設從未被驗證，而不是「App 功能不夠多」或「UI 不夠漂亮」。
注意：5 Whys 給出的是一條根因路徑，不是唯一根因。同一問題，不同的人、不同的起點，可能走出不同的因果鏈。這是業界對這個方法的已知批評（方法論層面的限制，非可佐證缺陷）。實務做法：多人各自跑一遍，再比對異同。
How Might We（HMW）
由 IDEO 推廣，廣泛應用於 Design Sprint、設計思考工作坊。形式是把問題改寫成「我們要怎樣才能……」，用正向、開放的語氣重新框架，把討論從「這件事辦不到」轉向「怎麼讓它成為可能」。
轉換範例：
| 原始陳述 | HMW 重構 |
|---|---|
| 「登入太麻煩」 | 「我們要怎樣才能讓回頭用戶一步完成登入？」 |
| 「文件沒人看」 | 「我們要怎樣才能讓文件在用戶最需要的時刻主動出現？」 |
| 「客服量太大」 | 「我們要怎樣才能讓 80% 的重複問題不需要人工回答？」 |
HMW 不直接定義解法，而是定義解法的方向。從同一個問題可以產生多個 HMW，用來探索不同的解題角度。
Job-to-be-Done（JTBD）
Clayton Christensen 提出，核心主張：用戶「僱用」一個產品，是為了完成某件「工作」（job），而不是因為喜歡這個產品本身。Framing 的角度從「用戶想要什麼功能」轉向「用戶在什麼情境下、要完成什麼任務」。
JTBD 問句框架：
當我在 ______（情境），我想 ______（動機/行動），這樣我就能 ______（期望結果）。
例：「當我剛加入一個新專案，我想快速了解程式庫的架構和慣例，這樣我就能在不踩地雷的情況下開始貢獻。」
這個 job 定義比「需要更好的 onboarding 文件」清楚得多——它點出了情境（新加入）、驅動力（不想踩地雷）、真正的結果（開始貢獻），而非功能（文件）。
問題陳述句（Problem Statement）
把 framing 收斂到一句可被測試的陳述，供後續 spec 使用：
[使用者/角色] 在 [情境] 中，需要 [達成什麼目標]，
但現在面臨 [障礙/痛點]，導致 [可量化的負面結果]。
這個陳述不包含解法，只包含問題。它是 framing 的輸出，也是 spec 的輸入。
常見反模式
Solution Bias（解法先入）：還沒定義問題就開始討論技術方案。常見徵兆是討論開頭出現「我們應該用 X 來…」。
Symptom Solving（治標不治本）：把症狀當問題，解決的是表面現象而非根本原因。5 Whys 就是為了打破這個模式而設計的。
Problem Anchoring（錨定效應）：第一個問法定義了後續討論的範圍，就算它是錯的。對策是刻意產生至少三種不同 framing，然後評估哪個最有解釋力。
Scope Creep in Disguise（假 framing 真擴範圍）：framing 過程變成加功能，不是定義問題。發現 HMW 清單裡有超過一半是「功能需求偽裝成問題陳述」時，這個警訊就亮了。
方法論主張 vs. 可佐證事實
可佐證：5 Whys 確實源自 Toyota 生產系統，並在製造業、軟體業有大量記錄案例。HMW 的起源可追溯至 1970 年代 P&G 的創意會議，後由 IDEO 在 Design Sprint 中推廣，現為 Google Design Sprint 官方工具之一。JTBD 理論由 Christensen 在《創新者的解答》（2003）中系統闡述，有學術引用基礎。
方法論主張（難以量化）：「先做 framing 能節省多少開發時間」沒有通用數字，各個引用的研究脈絡差異大。「5 Whys 一定能找到根因」也是誇大說法——它是啟發式工具，不是演繹系統。
延伸
- Framing 完成後，下一步是寫規格 → Spec-Driven Development：規格先行
- 如何在 framing 之前先確認你在問對問題 → 延伸：Interview Me 的角色
- 回到全景 → Problem Framing ＋ Spec-Driven Development 專欄首頁