設計思維入門

設計思維（design thinking） 不是「設計師才用的方法」，是任何解決複雜問題的人都可以用的一套思考流程。

它最常被歸功給設計顧問公司 IDEO（位於加州 Palo Alto）與史丹佛 d.school，但其根源可追溯到 1960 年代的工業設計與認知科學。

它解決什麼問題

傳統解決問題的方式經常踩兩個坑：

1. 太快跳到解法 — 還沒搞清楚使用者真正的需求，就開始畫畫面、寫程式
2. 解錯題目 — 解了一個技術上正確、但沒人需要的問題

設計思維逼你先理解、再定義、再發想、再做、再驗證，把這五個動作排成有紀律的順序。

IDEO 五階段流程

同理 → 定義 → 發想 → 原型 → 測試
(Empathize) (Define) (Ideate) (Prototype) (Test)

注意是非線性的 — 測試結果經常推你回到「定義」或「發想」階段重新開始。每本書、每個團隊會有自己的詞彙與步驟切分，但骨架都是這五個動作。

它不是什麼

• 不是只給創意產業用的 — IBM、IDEO、Google、Airbnb 都全公司在用
• 不是發散就好 — 它有嚴格的收斂步驟（「定義」就是收斂）
• 不是取代資料分析 — 它跟用戶研究、A/B 測試是互補關係
• 不是萬靈丹 — 對於「規格已定、只剩執行」的工作，它幫助有限

為什麼工程師也應該學

寫程式的人最容易掉進「我做得出來 = 該做」的思維。設計思維的核心是從『使用者真正的痛』反推要做什麼，而不是從『我手上的技術能做到什麼』正推。

下一章開始，我們逐一拆解五個階段。

目標：放下你自己的假設，鑽進使用者的世界裡。

這是最容易被工程師跳過的階段。理由通常是「我已經知道使用者要什麼了」— 但你十之八九不知道。

三個經典方法

1. 使用者訪談（user interview）

找 5-8 位「目標使用者」，每人聊 30-60 分鐘。問開放問題，不要引導：

• ❌ 「你會不會覺得我們 app 的首頁很複雜？」（暗示了答案）
• ✅ 「能跟我說說，你上次用我們 app 時做了什麼嗎？」

關鍵：問做了什麼，不要問會做什麼。人對「過去」的記憶比對「未來」的預測準確得多。

2. 沉浸式觀察（contextual inquiry）

到使用者實際的環境去看他們怎麼做事 — 不要在會議室裡。

為什麼？因為現場有太多你沒問到的線索：辦公室的噪音、桌上的便利貼、他們開了 12 個 Chrome 分頁、他們其實是邊用你的軟體邊跟同事講話。

3. 同理地圖（empathy map）

每位受訪者畫一張：

   說什麼？     |    做什麼？
   (SAYS)      |    (DOES)
  --------------+--------------
   想什麼？     |    感受到什麼？
   (THINKS)    |    (FEELS)

說與做經常不一致 — 那個落差通常是金礦。例如使用者「說」他在意隱私，但「做」的是用同一個密碼登入 20 個網站。

同理 ≠ 同情

同理是「我能感受到你的情緒」，同情是「我為你感到難過」。同理會驅動你做事，同情常停在情緒層面。

常見錯誤

• 只訪問身邊的人 — 朋友 / 同事不是你的目標使用者
• 過度抽樣 — 訪了 50 個人，但都是同一類人
• 問完就丟 — 沒整理成可用的洞察
• 太早收斂 — 「我訪了三個人都這樣說，應該夠了」

下一章：把訪談洞察轉成精準的問題定義。

目標：把上一階段蒐集到的雜亂資訊，收斂成一句明確的「問題陳述」。

好的問題陳述是後面所有發想的北極星。糟糕的問題陳述會讓團隊發想出很美但沒人要的方案。

POV 句式：使用者 + 需求 + 洞察

常見的問題陳述格式（IDEO 稱為「Point of View」）：

[使用者] 需要 [需求]，因為 [洞察]。

例：

一個在便利商店打工的高三學生 需要 一個能在 5 分鐘內完成的英文單字複習方式， 因為 他的休息時間被切得很碎、無法坐下來看書。

注意三個欄位都是具體的，不是抽象的：

• ❌ 學生需要更好的學習工具
• ✅ 在便利商店打工的高三學生需要 5 分鐘碎片化複習

「How Might We（HMW）」問句

把問題陳述翻譯成可以發想的問句：

HMW 為碎片時間有限的高中生，設計一套 5 分鐘可完成的英文單字複習？

HMW 的三個字各自重要：

• How — 預設「有方法」，問的是怎麼做
• Might — 給空間，不要「必須 / 一定」
• We — 是團隊一起，不是某個天才

一個好 HMW 的特徵

1. 範圍剛好 — 太寬「HMW 改善教育」沒辦法發想；太窄「HMW 把按鈕改成藍色」已經是解法
2. 以使用者為中心 — 提到具體的人或情境
3. 沒預設解法 — 「HMW 做一個 app」就是預設

親和性圖（affinity diagram）

收斂的工具：把所有訪談筆記寫到便利貼，貼在牆上，讓相似的自動聚集。聚成的群組通常就是 HMW 的種子。

常見錯誤

• 太快進到發想 — 沒有清楚 HMW，發想就會亂槍打鳥
• HMW 太寬 — 「HMW 讓人學得更好」⇒ 切到 50 個子問題
• HMW 偷藏解法 — 「HMW 用 AI 幫人學單字」⇒ 「AI」是解法，不是問題
• 跳過收斂 — 拿著一堆訪談筆記就開始畫畫面

下一章：發想階段如何在「品質」與「數量」之間取得平衡。

目標：在一個明確的 HMW 之下，產出大量、發散的解法。

核心信念：「想出 100 個爛點子比想出 10 個好點子，更容易找到 1 個傑出點子。」

經典工具：腦力激盪（brainstorming）

四條規則（Alex Osborn 1953）：

1. 延遲評斷 — 想出來再說，先別批判
2. 追求數量 — 至少 50 個，越多越好
3. 歡迎瘋狂 — 「不切實際」的點子通常是好點子的種子
4. 建立在別人想法上 — 不是各想各的

但是 — 集體腦力激盪其實有研究證實效率較低。研究發現一群人在一起想出來的點子數量與品質，往往不如同樣的人各自獨立想再合併。

為什麼？

• 「社交怠惰」（social loafing）：別人在想我就放鬆
• 「生產阻塞」（production blocking）：一次只能一個人講
• 「評斷顧慮」（evaluation apprehension）：怕被笑

改良版：Brainwriting（書面腦力激盪）

1. 每人發一張紙，3 分鐘獨立寫下自己的點子
2. 紙傳給下一個人，看別人的、寫新的或延伸
3. 重複 3-4 輪

比起說話，寫的速度差不多，但所有人同時寫，產出量翻倍。

SCAMPER 七字訣

卡關時用這七個動詞檢視一個既有方案：

字母	意義	例子
Substitute	取代	把「按鈕」換成「滑動」
Combine	結合	把兩個功能合併
Adapt	適應	借鑑遊戲的 onboarding
Modify	修改	放大 / 縮小 / 強調某部分
Put to other use	改變用途	給老人用的設計給小孩用
Eliminate	刪除	把這個欄位拿掉會怎樣？
Reverse	反轉	把流程倒過來

「壞點子優先」（worst possible idea）

卡關時的破冰技巧：刻意想最爛的解法。

例如「HMW 讓人記單字」：

• ❌ 最爛點子：每天用電擊提醒
• 反向：原來「強迫提醒」是討厭的，那「自願性回顧」呢？

何時停下

不是時間到才停，而是「這個 HMW 的點子明顯重複了」才停。如果還在出新東西，就繼續。

下一章：把最有潛力的點子做成可以測試的原型。

目標：用最低的成本，把點子變成「可以給人試用的東西」。

關鍵字是最低成本。原型不是成品，是用來學習的工具。

原型的「保真度」（fidelity）

低保真 ────────────────────────────── 高保真
 紙   →  線框  →  灰階  →  彩稿  →  可點擊  →  跑得動的程式

初期請盡量低保真。為什麼？

1. 快 — 紙原型 30 分鐘搞定，可點擊原型可能要 3 天
2. 便宜 — 丟掉重做不心痛
3. 歡迎批評 — 給人看一張潦草的紙，他敢說「這超爛」；給人看精美的 Figma，他會說「滿好的」（怕傷你心）
4. 聚焦在流程而非細節 — 紙上沒有「按鈕該圓還方」的爭論

紙原型（paper prototyping）

適合：流程設計、資訊架構、初期想法驗證

做法：

1. 把每個「畫面」畫在一張 A5 紙上
2. 互動元件（按鈕、選單）用便利貼貼上 — 可以撕下移動
3. 給使用者一支筆，請他「點」紙上的按鈕
4. 你扮演電腦，根據他點哪裡換下一張紙

意外地有效。Jakob Nielsen 的研究說紙原型發現的可用性問題，跟跑得動的程式發現的相似度高達 80%。

線框圖（wireframe）

常用工具：Balsamiq、Figma 的 wireframe 模式、甚至直接用白板。

重點是只畫骨架：色塊代表圖、橫線代表文字、長方形代表按鈕。不要花時間挑顏色、字型。

「奧茲法師」原型（Wizard of Oz）

讓使用者以為他在跟成品互動，其實後面是真人在操作。

經典例子：早期的語音助理 demo，使用者對著機器說話，背後是一個人用打字回答。

適合驗證「如果功能真的做出來、使用者會不會用」這類問題，不必先把昂貴的 AI 模型做出來。

服務藍圖（service blueprint）

當你設計的不只是一個畫面、而是一整段「使用者的體驗」時（例如：點餐 → 取餐 → 評分），畫服務藍圖：

使用者動作  | 點餐 | 等待 | 取餐 | 用餐 | 評分
他看到什麼  | 菜單 | 號碼 | 餐點 | 餐點 | 提示
背後有誰   | 收銀 | 廚房 | 服務生 | -- | 系統
用什麼系統  | POS | KDS  | --   | --  | App

別卡在「不完美就不能給人看」

設計師的本能是「再修一下再給人看」。請反過來：現在就給人看。每多 1 天打磨原型，少 1 天學到使用者真正的反應。

下一章：怎麼把原型放到使用者面前測試。

目標：讓使用者操作原型，看他們真實的反應，把學到的東西帶回去改。

一個基本原則

測試使用者，不是測試使用者的耐心。

別把測試變成「我教你怎麼用」。如果使用者卡住、你忍不住想出手 — 忍住，把那個卡住記下來。

5 個使用者法則

Jakob Nielsen 的研究：用 5 個使用者，能找到 85% 的可用性問題。

為什麼是 5？因為每多測 1 個人，新發現的問題會以遞減速度增加。15 人發現的問題，第 6-15 個只多揭露 15%。比起多測 5 個人，用同樣的時間做下一版原型再測 5 個人 學到更多。

測試流程

1. 介紹（2 分鐘）

   • 「我們在測試的是這個原型，不是你。卡住是它的錯，不是你的錯。」
   • 「請邊操作邊把你在想的說出來（think-aloud protocol）。」

2. 任務（15-30 分鐘）

   • 給具體任務：「請你預訂一張明天到台北的高鐵票」
   • 不要說：「請你看一下這個 app 有什麼問題」

3. 觀察

   • 記錄：他卡在哪裡？哪裡笑了？哪裡皺眉？他點了什麼地方但其實不能點？

4. 訪談（5-10 分鐘）

   • 「剛剛你卡在 X 那裡，當時在想什麼？」
   • 「如果這個 app 真的出了你會用嗎？哪些情境會用？」

三種發現怎麼分類

  影響嚴重程度
   高 | 急修 (must) | 規劃 (should)
      |─────────────|──────────────
   低 | 之後修 (could) | 不修 (won't)
        高頻             低頻

5 個使用者中有 3 個都卡住的問題 = 急修。 只有 1 個人卡住、但他卡到大爆炸 = 規劃。

別問「你喜不喜歡」

「你喜歡這個 app 嗎？」 → 答案永遠是「喜歡 / 還好」，因為他在跟你（設計者）對話，要禮貌。

改問「你會願意付 100 元下載嗎？」「你會推薦給你哪個朋友？」這類承諾性的問題，答案會誠實得多。

A/B 測試 vs 可用性測試

兩種測試解決不同問題：

	A/B 測試	可用性測試
樣本	上千	5-8 個
問題類型	哪個版本轉換率高？	為什麼使用者卡住？
何時用	上線後優化	設計階段
答案類型	數字	故事

設計階段用可用性測試找問題，上線後用 A/B 測試驗證解法。

測試結果回流到哪個階段？

不一定是改原型 — 經常是回到更早的階段：

• 測試發現「使用者根本不需要這個功能」→ 回到定義
• 測試發現「使用者要的是另一種方式」→ 回到發想
• 測試發現「介面細節要改」→ 改原型

下一章：實際把這五個階段套到一個 case 上。