Design Thinking（設計思考）是一套以人為本的問題解決方法論，強調同理心、快速迭代與跨域協作。這篇文章完整解析設計思考五步驟流程、雙鑽石進階框架、三種規模的真實案例，以及你能直接套用的工作坊議程與數位工具。
設計思考是什麼？一句話定義與核心精神
設計思考（Design Thinking）是一套以使用者為中心的創新方法論，核心目標是：先找對問題，再解決問題。
它不是設計師的專利。PM、產品經理、營運主管、甚至人資部門，只要你的工作涉及「為某群人解決某個問題」，設計思考就是你的思維工具。
設計思考有三個核心特徵：
- 以人為本（Human-Centered）：所有決策從使用者的真實需求出發，而非組織內部的假設
- 非線性迭代：五個步驟可以反覆來回，不是做完一步才能進下一步
- 跨域協作：刻意邀請不同背景的人參與，打破部門穀倉
很多人會問：「這跟傳統的問題解決方法有什麼不同？」差異在於思維順序。
| 面向 | 傳統線性思維 | 設計思考 |
|---|---|---|
| 起點 | 從已知解法出發 | 從使用者痛點出發 |
| 流程 | 線性、不可逆 | 非線性、可迭代 |
| 失敗觀 | 失敗是成本 | 失敗是學習 |
| 參與者 | 單一部門決策 | 跨域團隊共創 |
| 產出 | 完整方案 | 最小可測試原型 |
傳統方法像是「先射箭再畫靶」——主管說要做什麼功能，團隊就做。設計思考則是「先確認靶在哪裡」——花時間理解使用者到底卡在哪裡，再決定要射哪支箭。
這個思維轉換聽起來簡單，但我們團隊在實際導入時發現，光是「先別急著想解法」這一步，就能讓跨部門會議的品質提升一個層次。搭配好的流程圖工具，整個設計思考流程會更容易視覺化與追蹤。
設計思考的起源與發展脈絡
設計思考不是憑空出現的流行詞。它的根源可以追溯到 1960 年代的設計方法論研究，但真正讓它成為商業主流的，是兩個關鍵推手：IDEO 設計公司和史丹佛大學 d.school。
IDEO 的創辦人 David Kelley 在史丹佛成立了 Hasso Plattner Institute of Design（簡稱 d.school），將設計思考從工業設計領域帶入商學院。IDEO 的執行長 Tim Brown 則透過《設計思考改造世界》一書，讓全球企業開始認真看待這套方法論。
從工業設計到商業策略，設計思考的應用範圍不斷擴大。在台灣，台灣設計研究院（原台灣創意設計中心）積極推動設計思考在公共服務與產業的應用，許多企業也開始將設計思考納入數位轉型策略中。
為什麼現在是學習設計思考的關鍵時機？因為市場競爭已經從「功能競爭」轉向「體驗競爭」。當產品功能趨於同質化，誰更懂使用者、誰能更快迭代，誰就贏。這正是設計思考的主場。
設計思考五步驟完整解析
設計思考的五個步驟由史丹佛 d.school 定義，分別是：同理（Empathize）、定義（Define）、發想（Ideate）、原型（Prototype）、測試（Test）。
重要的是：這五個步驟不是瀑布式的線性流程。你可能在測試階段發現問題定義錯了，需要回到同理階段重新理解使用者。這種「迭代」才是設計思考的精髓。
步驟一：同理（Empathize）
目標：深入理解使用者的真實需求，而非你以為的需求。
同理是整個設計思考流程中最容易被跳過、卻最關鍵的步驟。多數專案失敗不是因為解法不好，而是因為一開始就在解決錯誤的問題。
常用方法：
- 使用者訪談：一對一深度訪談，用開放式問題引導使用者說出真實經驗。關鍵技巧是「追問為什麼」——當使用者說「我覺得這個功能不好用」，你要追問「可以跟我說上一次你用這個功能時發生了什麼事嗎？」
- 田野觀察：到使用者的實際環境中觀察他們的行為，而非只聽他們怎麼說。人們說的和做的往往不一樣
- 同理心地圖（Empathy Map）：將觀察到的資訊整理成四個象限——使用者「說了什麼」「做了什麼」「想了什麼」「感受到什麼」
台灣情境案例： 某電商平台的 PM 團隊發現 55 歲以上用戶的結帳完成率只有年輕用戶的一半。他們沒有直接「把按鈕放大」，而是先到用戶家中觀察長輩實際使用手機購物的過程。結果發現問題不在按鈕大小，而是付款方式選擇頁面的文字描述讓長輩搞不清楚「超商取貨付款」和「貨到付款」的差異。這個洞察來自觀察，不是來自假設。
如果你想系統化地設計訪談問卷，可以參考問卷設計的方法論，確保你問對問題。
步驟二：定義（Define）
目標：將同理階段收集到的大量資訊，收斂成一個清晰的問題陳述。
這個步驟的核心工具是 How Might We（HMW）問句——「我們可以如何⋯⋯？」這個句型的魔力在於：它既承認問題的存在，又暗示解決的可能性。
HMW 問句的寫法有三個原則：
- 不能太大：「我們可以如何改善使用者體驗？」→ 太模糊，無法行動
- 不能太小：「我們可以如何把按鈕從藍色改成綠色？」→ 已經預設了解法
- 剛剛好：「我們可以如何讓 55 歲以上用戶在付款頁面做出自信的選擇？」→ 聚焦問題，但不限制解法
| HMW 問句品質 | 範例 | 問題 |
|---|---|---|
| ❌ 太廣 | 我們可以如何讓產品更好？ | 無法聚焦行動 |
| ❌ 太窄 | 我們可以如何加一個教學彈窗？ | 已預設解法 |
| ✅ 剛好 | 我們可以如何讓新用戶在 5 分鐘內完成第一個任務？ | 聚焦問題，開放解法 |
另一個實用工具是使用者旅程地圖（User Journey Map），它把使用者從「第一次接觸」到「完成目標」的每個階段攤開來看，標記出情緒高低點和痛點。我們團隊在做旅程地圖時，習慣用 Miro 的線上白板，因為遠端團隊可以同步協作，而且內建的便利貼和投票功能特別適合這個階段。
台灣情境案例： 一家 B2B SaaS 公司的客服團隊每月處理超過 300 張工單，其中 40% 都是「不知道怎麼開始使用」。PM 團隊用 HMW 問句重新定義問題：「我們可以如何讓新客戶在不聯繫客服的情況下，獨立完成產品設定？」這個問題定義直接改變了後續的解法方向——從「增加客服人力」轉向「重新設計 onboarding 流程」。
步驟三：發想（Ideate）
目標：不設限地產出大量解法，刻意延遲評判。
發想階段的第一條規則是：數量優先於品質。先追求 50 個點子，再從中挑選。多數團隊的問題不是缺乏好點子，而是太早否定點子。
常用方法：
- 腦力激盪（Brainstorming）：經典方法，但要遵守規則——不批評、鼓勵瘋狂想法、在別人的點子上延伸、一次一個人發言
- SCAMPER：七個思考角度的檢查清單——替代（Substitute）、結合（Combine）、調整（Adapt）、修改（Modify）、另作他用（Put to other uses）、消除（Eliminate）、重組（Rearrange）
- 六頂思考帽：讓團隊成員輪流戴上不同顏色的「帽子」，從不同角度思考同一個問題
台灣情境案例： 某製造業公司要改善產線效率，跨部門工作坊邀請了生產、品管、業務、IT 四個部門共 12 人。用 20 分鐘的便利貼腦力激盪，產出了 57 個解法。其中一個看似瘋狂的點子——「讓業務人員每月到產線工作半天」——最後成為最有效的改善方案，因為它解決了業務接單時不理解產能限制的根本問題。
在遠端團隊中，腦力激盪需要好的數位工具支撐。我們測試過多種線上白板，發現 Miro 的便利貼功能最接近實體工作坊的體驗——每個人可以同時貼便利貼，不會被「誰先發言」的順序限制。
發想階段結束後，用投票法（Dot Voting）快速收斂：每人 3 票，貼在最有潛力的點子上。這個方法簡單但有效，能在 5 分鐘內從 50 個點子收斂到 3-5 個進入原型階段。
步驟四：原型（Prototype）
目標：快速製作低成本、可測試的解決方案。
原型的關鍵字是「快」和「低成本」。你不是在做最終產品，你是在做一個「可以拿去問使用者意見的東西」。
原型的形式取決於你要測試什麼：
- 紙本原型：用紙筆畫出介面草圖，適合測試流程邏輯。成本幾乎為零，10 分鐘就能做出來
- 線框圖（Wireframe）：用 Figma 或 FigJam 做出可點擊的低保真原型，適合測試互動流程
- MVP（最小可行產品）：只做核心功能的簡化版本，適合驗證商業假設
台灣情境案例： 一家新創團隊想測試「AI 自動生成週報」的功能是否有市場需求。他們沒有花三個月開發 AI 模型，而是用 Figma 做了一個可點擊的原型——畫面上有「生成週報」按鈕，點下去會顯示一份預先寫好的範例週報。拿這個原型去給 15 位目標用戶測試，3 天就得到了足夠的回饋來決定是否值得投入開發資源。
這個階段的重點是：不要愛上你的原型。它是用來被批評的，不是用來被保護的。
步驟五：測試（Test）
目標：從真實使用者的回饋中學習，決定迭代方向。
測試不是「展示你做了什麼」，而是「觀察使用者怎麼用」。最有價值的測試回饋往往來自使用者的行為，而非他們的嘴巴。
常用方法：
- 可用性測試（Usability Testing）：請使用者完成特定任務，觀察他們在哪裡卡住。關鍵是不要引導——當使用者猶豫時，忍住不要說「你可以點那個按鈕」
- A/B 測試：同時測試兩個版本，用數據決定哪個更好
- 回饋矩陣：將回饋分成四個象限——「喜歡的」「想改變的」「有疑問的」「新想法」
台灣情境案例： 某金融科技公司重新設計了線上開戶流程，原型測試時邀請了 8 位不同年齡層的用戶。測試發現一個意外的摩擦點：身分證拍照上傳步驟中，用戶不確定「正面」是指有照片的那面還是有條碼的那面。這個問題在內部測試時從未被發現，因為團隊成員太熟悉自己的產品了。修正後，開戶完成率提升了 23%。
測試階段的產出不是「通過/不通過」，而是一份清晰的迭代清單。哪些假設被驗證了？哪些需要回到定義階段重新思考？這就是設計思考「非線性」的具體體現。
如果你需要把測試結果整理成企劃書向主管提案下一階段的開發計畫，建議用結構化的格式呈現數據，說服力會更強。
雙鑽石模型：設計思考的進階框架
如果你已經熟悉五步驟，下一個要認識的框架是雙鑽石模型（Double Diamond）。它由英國設計協會（Design Council）提出，用兩個菱形來描述設計流程中「發散」與「收斂」的交替。
四個階段：
- 發現（Discover）：發散——廣泛探索問題空間，收集使用者洞察
- 定義（Define）：收斂——從大量資訊中聚焦到核心問題
- 發展（Develop）：發散——針對核心問題產出多種解法
- 交付（Deliver）：收斂——選擇最佳解法，打磨並推出
雙鑽石和五步驟不是互相取代的關係，而是不同層級的框架：
| 雙鑽石階段 | 對應五步驟 | 思維模式 |
|---|---|---|
| 發現 Discover | 同理 Empathize | 發散：廣泛探索 |
| 定義 Define | 定義 Define | 收斂：聚焦問題 |
| 發展 Develop | 發想 Ideate + 原型 Prototype | 發散：多元解法 |
| 交付 Deliver | 測試 Test | 收斂：驗證交付 |
什麼時候用哪個？ 如果你是第一次帶團隊做設計思考，用五步驟——它更具體、更容易操作。如果你的組織已經有設計思考的基礎，想要建立更系統化的創新流程，雙鑽石模型提供了更好的策略視角。
台灣的大型企業（特別是金融業和製造業）在導入設計思考時，往往從雙鑽石的「發現」階段開始，因為這些組織最缺的不是解法，而是對使用者的深入理解。這也呼應了商業模式設計中「價值主張必須從客戶需求出發」的核心原則。
設計思考真實案例：3 個不同規模的應用情境
理論說完了，來看三個不同規模的團隊如何實際運用設計思考。
大型企業案例：Netflix 如何用設計思考重塑推薦體驗
Netflix 面臨的問題很具體：用戶平均花 90 秒選片，如果超過這個時間還沒找到想看的內容，就會關掉 App。這就是所謂的「選擇疲勞」。
Netflix 的設計團隊沒有直接優化推薦演算法，而是先回到同理階段——大規模使用者研究發現，用戶不是「找不到好內容」，而是「不確定這個內容是否適合現在的心情」。
基於這個洞察，他們重新定義問題：「我們可以如何幫助用戶在 30 秒內找到符合當下心情的內容？」接著快速原型測試了多種方案，包括「Top 10 排行榜」、「因為你看了 XX」推薦列、以及自動播放預覽。每個方案都經過 A/B 測試，最終組合出現在你看到的 Netflix 首頁體驗。
結果：觀看完成率顯著提升，用戶留存率改善。
中型企業案例：台灣 B2B SaaS 團隊的 90 天轉型
一家約 40 人的台灣 SaaS 公司，產品是企業內部的知識管理系統。問題是：新客戶簽約後，只有 35% 在 30 天內完成產品設定並開始使用。其餘 65% 的客戶要嘛拖延、要嘛直接流失。
PM 團隊用 90 天跑了一輪完整的設計思考流程：
- 同理（第 1-3 週）：訪談了 20 位客戶，包括成功導入和放棄導入的。發現關鍵洞察：客戶不是不想用，而是「不知道第一步該做什麼」。產品功能太多，客戶被選項淹沒了
- 定義（第 4 週）：HMW 問句——「我們可以如何讓新客戶在不需要客服協助的情況下，在 1 小時內完成核心設定？」
- 發想（第 5-6 週）：跨部門工作坊產出 40+ 個點子，收斂到 3 個方向——互動式引導教學、簡化版設定精靈、客戶成功經理主動外撥
- 原型（第 7-9 週）：選擇「簡化版設定精靈」做原型，只保留 5 個必要步驟，其餘設定延後
- 測試（第 10-12 週）：邀請 10 位新客戶使用新流程，觀察他們的操作過程
結果：導入完成率從 35% 提升到 75%，客服工單減少 40%。
這個案例的關鍵學習是：解法不一定是「加功能」，有時候是「減功能」。
個人/小團隊案例：PM 用設計思考解決內部流程痛點
你不需要一個大專案才能用設計思考。一位在 15 人團隊中工作的 PM，發現跨部門需求收集一直是痛點——業務用 LINE 傳需求、行銷用 Email、客服用口頭轉達，PM 每週花 5 小時整理這些散落各處的資訊。
這位 PM 用設計思考的思維，花了兩週解決這個問題：
- 同理：分別跟業務、行銷、客服聊了 30 分鐘，問他們「為什麼用現在的方式提需求？」發現原因不是他們不想用統一系統，而是「之前的表單太複雜，填完要 15 分鐘」
- 定義：「我們可以如何讓提需求這件事在 3 分鐘內完成？」
- 發想：列出 10 個可能的解法
- 原型：在 monday.com 上建了一個簡化的需求看板，只有 4 個必填欄位——需求標題、優先級、期望完成日、一句話描述
- 測試：請三個部門試用一週，收集回饋後微調
結果：需求確認時間從平均 3 天縮短到半天，PM 每週省下 4 小時的整理時間。而且因為所有需求都在同一個看板上，主管也能即時看到全貌，不用再開「需求盤點會議」。
| 案例規模 | 問題 | 設計思考應用 | 結果 |
|---|---|---|---|
| 大型企業（Netflix） | 用戶選片時間過長導致流失 | 大規模使用者研究 → 定義「選擇疲勞」→ A/B 測試推薦方案 | 觀看完成率與留存率提升 |
| 中型企業（台灣 SaaS） | 新客戶導入完成率僅 35% | 訪談 20 位客戶 → 重新設計 onboarding → 原型測試 | 導入完成率提升至 75% |
| 個人/小團隊（PM） | 跨部門需求收集混亂 | 訪談各部門 → 簡化需求表單 → 一週測試 | 需求確認時間縮短，每週省 4 小時 |
設計思考 vs. 敏捷開發：互補而非競爭
「我們公司已經在跑敏捷了，還需要設計思考嗎？」這是我們最常被問到的問題之一。
答案是：設計思考和敏捷開發解決的是不同階段的問題。設計思考幫你「找對問題」，敏捷開發幫你「快速交付解法」。它們不是競爭關係，而是前後銜接的互補關係。
| 面向 | 設計思考 | 敏捷開發 |
|---|---|---|
| 核心問題 | 我們在解決對的問題嗎？ | 我們能多快交付解法？ |
| 適用階段 | 專案前期（探索與定義） | 專案中後期（開發與交付） |
| 週期 | 數天到數週（視研究深度） | 1-4 週（Sprint） |
| 主要產出 | 問題定義、使用者洞察、原型 | 可運作的軟體增量 |
| 參與者 | 跨域團隊（含非技術人員） | 開發團隊為主 |
| 失敗成本 | 低（紙本原型、訪談） | 中（已投入開發資源） |
實務上的整合方式是 Discovery Sprint——在正式的敏捷 Sprint 之前，先跑一到兩週的「發現衝刺」。在這個階段，團隊用設計思考的方法做使用者研究、定義問題、產出原型並測試。Discovery Sprint 的產出直接轉化為敏捷 Sprint 的 Product Backlog。
何時先用設計思考？ 當你面對的是一個模糊的問題——不確定使用者要什麼、不確定市場方向、或者現有方案的滿意度持續下降。
何時直接進敏捷？ 當問題已經很清楚——使用者明確要求某個功能、Bug 修復、或者已驗證的需求要快速交付。
這個判斷框架跟艾森豪矩陣的邏輯類似——先判斷事情的性質，再決定用什麼方法處理。
設計思考常用工具與模板
工欲善其事，必先利其器。以下是我們團隊實際測試過、適合設計思考各階段的工具。
數位協作工具
在遠端或混合辦公的環境下，數位工具是設計思考能否落地的關鍵。
| 工具 | 最適合的階段 | 費用 | 中文介面 | 特色 |
|---|---|---|---|---|
| Miro | 同理、發想、定義 | 免費方案可用，付費約 NT$400/月/人 | ✅ | 內建設計思考模板庫，便利貼與投票功能最佳 |
| Notion | 定義、測試（研究筆記整理） | 免費方案可用 | ✅ | 適合整理訪談紀錄、HMW 問句、回饋矩陣 |
| monday.com | 原型、測試（專案追蹤） | 免費方案可用，免信用卡 | ✅ | 適合追蹤設計思考專案進度與任務分配 |
| ClickUp | 全流程（技術團隊） | 免費方案可用 | 部分 | 白板 + 專案管理一體化，適合技術導向團隊 |
我們團隊的實際用法是：用 Miro 做工作坊的即時協作（腦力激盪、旅程地圖、同理心地圖），用 Notion 整理研究筆記和訪談逐字稿，用 monday.com 追蹤整個設計思考專案的時程和任務分配。三個工具各司其職，不會互相衝突。
（推薦試試 monday.com 的免費方案，我們團隊實際使用後發現它的看板視圖特別適合追蹤設計思考各階段的進度，免費方案不需要信用卡。）
實體工作坊工具
如果你的團隊是面對面工作，這些低成本工具同樣有效：
- 便利貼矩陣（Affinity Diagram）：把訪談中收集到的資訊寫在便利貼上，然後分組歸類。這是整理質性資料最直覺的方法
- 同理心地圖海報：A1 大小的海報，分成四個象限，貼在牆上讓團隊共同填寫
- 投票貼紙（Dot Voting）：每人 3-5 個圓點貼紙，貼在最有潛力的點子上。5 分鐘內就能從 50 個點子收斂到前 5 名
模板資源推薦
- IDEO Design Kit：免費英文資源，包含完整的設計思考方法卡片和工作坊指引
- 台灣設計研究院：定期發布中文設計思考工具包，適合台灣在地情境
- Miro 模板庫：內建數十種設計思考模板，包括同理心地圖、使用者旅程地圖、腦力激盪板，直接套用即可
如果你習慣用筆記軟體整理研究資料，Notion 的資料庫功能特別適合管理大量的訪談紀錄和使用者洞察。
如何在團隊中推動設計思考：從工作坊到文化落地
知道設計思考是什麼是一回事，讓團隊真正開始用是另一回事。以下是三個導入層次，從最容易到最困難。
第一層：單次工作坊（1-2 週準備）
最低門檻的起步方式。找一個具體的問題，辦一場 2 小時的工作坊，讓團隊體驗設計思考的流程。
以下是我們實際跑過的 2 小時工作坊議程：
| 時間 | 活動 | 說明 |
|---|---|---|
| 0:00-0:10 | 破冰 + 設計思考簡介 | 用一個 60 秒的小遊戲暖場，再用 5 分鐘說明今天的流程 |
| 0:10-0:30 | 同理：使用者故事分享 | 每人分享一個與主題相關的真實經驗，其他人用便利貼記錄關鍵洞察 |
| 0:30-0:45 | 定義：HMW 問句 | 根據洞察，每人寫 3 個 HMW 問句，投票選出最佳問題 |
| 0:45-1:05 | 發想：瘋狂八分鐘 | 每人在 A4 紙上畫 8 格，8 分鐘內畫出 8 個解法草圖 |
| 1:05-1:15 | 投票收斂 | Dot Voting 選出前 3 個解法 |
| 1:15-1:40 | 原型：快速製作 | 分組用紙筆製作簡易原型 |
| 1:40-1:55 | 測試：互相測試 | 各組交換原型，扮演使用者測試並給回饋 |
| 1:55-2:00 | 反思 + 下一步 | 討論今天的學習和後續行動 |
第二層：專案流程嵌入（1-3 個月）
在特定專案中正式導入設計思考流程。通常從一個中型專案開始，指定一位「設計思考推動者」負責引導團隊走完五步驟。
第三層：組織文化轉型（6-12 個月以上）
將設計思考融入組織的日常決策流程。這需要高層的支持，以及持續的培訓和實踐。
常見阻力與破解方法
我們在協助團隊導入設計思考時，最常遇到三種阻力：
「沒時間做使用者研究」 → 破解：不需要做三個月的研究。5 次 30 分鐘的使用者訪談，就能獲得比「會議室裡猜測」好 10 倍的洞察。把它框定為「一週的投資」，而非「額外的工作」。
「主管不支持」 → 破解：用 ROI 語言說明。不要說「我們要做設計思考」，要說「我們要花一週時間驗證這個功能是否值得投入三個月開發」。前面提到的 SaaS 案例——導入完成率從 35% 提升到 75%——就是最好的說服素材。培養主管領導力的過程中，學會用數據說服上級是必備技能。
「成效難量化」 → 破解：在開始之前就定義成功指標。例如：「使用者完成率提升 X%」、「客服工單減少 X%」、「專案返工次數減少」。設計思考的成效不是「我們做了很棒的工作坊」，而是「我們解決了一個之前解決不了的問題」。
台灣企業常見的失敗模式
- 只做一次工作坊就宣告「我們導入了設計思考」：設計思考是持續的實踐，不是一次性的活動
- 把設計思考當成設計部門的事：如果只有設計師在做，就失去了「跨域協作」的核心價值
- 跳過同理階段直接發想：這是最常見也最致命的錯誤。沒有使用者洞察的發想，只是一群人在猜測
避免這些失敗模式的關鍵是：從小處開始，用成果說話，再逐步擴大。先用一個小專案證明設計思考的價值，再推廣到更多專案。這跟進入心流狀態的邏輯一樣——從能力匹配的挑戰開始，逐步提升難度。
設計思考學習資源：書單、課程與社群
推薦書單（繁體中文優先）
- 《設計思考改造世界》（Tim Brown 著，聯經出版）：設計思考的經典入門書，IDEO 執行長親自撰寫，案例豐富且易讀。適合第一次接觸設計思考的讀者
- 《設計思考全攻略》（Jeanne Liedtka 著）：更偏實務操作，提供大量工具和模板。適合想要在組織中推動設計思考的 PM 和主管
- 《這就是服務設計思考》（This is Service Design Thinking）：將設計思考延伸到服務設計領域，適合服務業和 B2B 產業的讀者
線上課程
- Coursera 產品管理課程：IDEO 與史丹佛 d.school 合作的設計思考課程，英文授課，部分有中文字幕。系統化程度最高，適合想要深入學習的人
- 台灣設計研究院：定期舉辦中文設計思考工作坊，費用約 NT$3,000-8,000，適合偏好面對面學習的人
- Hahow 好學校：中文設計思考入門課程，價格親民，適合自學入門
台灣社群與活動
- Service Design Network Taiwan 分會：台灣最活躍的服務設計社群，定期舉辦分享會和工作坊
- 各縣市創業基地：如台北創新實驗室、高雄創業基地等，經常舉辦免費或低成本的設計思考工作坊
如果你在學習過程中遇到冒牌者症候群——覺得自己「不是設計師，沒資格用設計思考」——請記住：設計思考的創始者們一再強調，這套方法論是給所有人的，不只是設計師。
結論
設計思考不是一套複雜的理論，而是一種「先理解人，再解決問題」的思維方式。回顧本文的重點：
- 設計思考是以人為本的問題解決方法論，核心是同理心、非線性迭代與跨域協作，適用於所有需要解決問題的角色
- 五步驟（同理→定義→發想→原型→測試）是可迭代的循環，不是線性流程。最常被跳過的「同理」步驟，恰恰是成敗關鍵
- 雙鑽石模型是五步驟的進階框架，用「發散→收斂」的節奏幫助團隊在對的時間做對的事
- 設計思考與敏捷開發互補：設計思考找對問題，敏捷開發快速交付。用 Discovery Sprint 銜接兩者
- 從小處開始：一場 2 小時的工作坊、一個簡化的需求表單，都是設計思考的實踐。不需要等到「完美的時機」
你的下一步行動： 選一個你現在手上最頭痛的問題，花 30 分鐘跟 3 位相關的同事聊聊他們的真實感受。不要急著想解法，先聽。這就是設計思考的第一步。
如果你想把設計思考的流程系統化地管理起來，建議在 monday.com 上建立一個設計思考專案看板——用不同的群組對應五個步驟，每個步驟的任務、負責人和截止日一目了然。免費方案就能開始，不需要信用卡。
Design Thinking 設計思考常見問題
設計思考和 UX 設計有什麼不同？
UX 設計（使用者體驗設計）是設計思考的一個應用領域。設計思考是更廣泛的問題解決方法論，可以應用在產品設計、服務改善、組織流程優化、甚至公共政策制定。UX 設計師經常使用設計思考的方法，但設計思考的使用者不限於設計師。
設計思考一定要五個步驟都做嗎？
不一定。五步驟是完整的框架，但實務上你可以根據情境調整。例如，如果你已經有充分的使用者研究資料，可以從「定義」步驟開始。重點是理解每個步驟的目的，而非機械式地走完流程。
小團隊沒有預算做使用者研究怎麼辦？
使用者研究不一定需要大預算。5 次 30 分鐘的線上訪談（用免費的視訊工具就行）、觀察同事使用產品的過程、或者分析客服工單中的常見問題，都是零成本的使用者研究方法。關鍵不是預算，而是「願意花時間理解使用者」的態度。
設計思考適合什麼類型的問題？
設計思考最適合「模糊的、以人為中心的問題」——你不確定問題的根本原因是什麼，或者現有的解法都不奏效。如果問題已經很明確（例如「系統有 Bug」），直接修復即可，不需要跑設計思考流程。
如何說服主管支持設計思考？
不要用「設計思考」這個詞，用主管聽得懂的語言。例如：「我想花一週時間訪談 5 位客戶，驗證我們下一季要開發的功能是否真的是客戶最需要的，避免花三個月開發出沒人用的東西。」用風險管理和 ROI 的角度切入，比用方法論的名詞更有說服力。
