HMW 提問法 How Might We

什麼時候該用它？

當你完成了使用者研究，手上有一堆洞察和痛點，但不知道怎麼把它們變成「可以開始設計的題目」的時候。HMW 是洞察和創意之間的橋樑。

• 使用者研究之後：訪談做完了，痛點整理出來了，然後呢？
• Design Sprint Day 1：畫完旅程地圖後，要把機會點轉化為可發想的問題
• Brainstorming 前：好的 brainstorming 需要好的問題，HMW 就是那個問題
• 團隊對齊：讓大家對「我們要解決什麼」達成共識
• 把抱怨變成機會：客訴和負面回饋都可以用 HMW 重新框架

框架結構

基本語法

「我們如何能 [動詞] [對象] [情境/條件]？」

範例：

• ❌ 太窄：「我們如何能在結帳頁加一個倒數計時器？」（這已經是解法了）
• ❌ 太廣：「我們如何能讓使用者更開心？」（無從下手）
• ✅ 剛好：「我們如何能讓新客在第一次結帳時感到安心？」

三個調節旋鈕

1. 放大（Amplify）：把好的部分放到最大 → 「我們如何能讓回購的體驗比首購還好？」
2. 反轉（Reverse）：把壞的東西翻過來 → 「我們如何能讓退貨變成正面的品牌體驗？」
3. 探索（Explore）：從完全不同的角度切入 → 「我們如何能讓使用者不需要退貨？」

從痛點到 HMW 的轉化公式

來源與歷史

• 1970s：Procter & Gamble 的 Min Basadur 最早在企業內部使用 HMW 格式做創新工作坊
• 2012：Google 的設計團隊在 Design Sprint 中將 HMW 標準化為必備環節
• 2016：Jake Knapp 在《Sprint》書中詳細介紹了 HMW 的使用方法，推向主流
• 至今：HMW 成為設計思維和敏捷開發的標配工具，幾乎所有 PM/UX 課程都會教

真實案例：Google 搜尋體驗優化

Google 搜尋團隊在改善行動搜尋體驗時，用 HMW 重新框架問題：

原始洞察：使用者在手機上搜尋時，常常因為網頁載入太慢而放棄。

HMW 發想：

1. HMW 讓搜尋結果在使用者點擊前就開始載入？→ AMP（Accelerated Mobile Pages）
2. HMW 在網頁還沒完全載入時就讓使用者看到有用的內容？→ 精選摘要（Featured Snippets）
3. HMW 讓使用者根本不需要離開搜尋頁面就得到答案？→ Knowledge Panel

結果：精選摘要功能讓搜尋結果頁的使用者滿意度提升 12%，而 AMP 頁面的載入速度平均快了 4 倍。

這些突破性的功能都來自同一個痛點的不同 HMW 角度。

使用步驟

Step 1：收集洞察和痛點

把使用者研究中發現的痛點、需求、觀察寫在便利貼上。一張一個洞察。

Step 2：轉化為 HMW 格式

每個痛點寫 2-3 個 HMW 問題。用放大/反轉/探索三個旋鈕產生不同角度。

Step 3：貼上牆，無聲投票

把所有 HMW 便利貼貼在牆上，每人 3 個圓點貼紙投票。投票標準：「哪個問題最值得花時間去解？」

Step 4：選出 Top 3

取得票最高的 3 個 HMW 作為後續 brainstorming 的起點。

Step 5：用 HMW 驅動 Ideation

把選出的 HMW 寫在白板頂部，然後用 Crazy 8s 或其他發想方法產出解法。每個解法都要回答那個 HMW。

這樣做 vs 避免這些

這樣做

• 一個痛點寫多個 HMW — 不同角度會帶出不同的創意
• 用「我們如何能」開頭而非「我們應該」— 前者激發可能性，後者暗示唯一解
• 在 HMW 後面加條件限制 — 「在不增加成本的情況下」讓問題更聚焦
• 讓非 PM 也參與 — 客服、業務、工程的 HMW 角度往往很不一樣

避免這些

• 不要把解法寫成 HMW — 「我們如何能加一個聊天機器人」不是 HMW，「我們如何能讓使用者隨時得到幫助」才是
• 不要太抽象 — 「我們如何能改變世界」沒有意義
• 不要只做一輪 — 第一輪的 HMW 通常太表面，多做幾輪會越來越深入
• 不要跳過投票直接做 — 沒有篩選的 HMW 會讓後續 brainstorming 失焦