設計思考工具不是軟體清單，而是工作坊任務的協作方法
設計思考工具的重點，是幫團隊把同理、定義、發想、原型與測試變成可共同操作的流程。Miro 和 FigJam 在工作坊中最有價值的地方，是讓觀察、便利貼、投票、畫布與決策留在同一個協作空間。
很多團隊找「設計思考工具」時，會先問要買哪個軟體。這個問題太早了。真正該先確認的是：這場工作坊要讓參與者理解什麼問題、產出什麼判斷、帶走什麼下一步。
設計思考五步驟與工具任務對照
| 設計思考階段 | 工具任務 | 常用畫布 | 主要產出物 |
|---|---|---|---|
| 同理 | 整理使用者觀察與訪談內容 | 同理心地圖、使用者旅程地圖 | 痛點、情緒、需求假設 |
| 定義 | 收斂問題邊界與優先議題 | 親和圖、5W2H、How Might We | 問題句、設計挑戰 |
| 發想 | 產生多個方案並做初步篩選 | 腦力激盪、Crazy 8s、點投票 | 候選點子、優先方案 |
| 原型 | 把想法轉成可討論的草稿 | 故事板、流程草圖、低保真 wireframe | 方案草圖、測試版本 |
| 測試 | 整理回饋並判斷是否修正 | 測試紀錄表、回饋分類表 | 回饋摘要、下一輪假設 |
Miro、FigJam 在這裡扮演的是「協作環境」，不是方法本身
Miro 和 FigJam 不會自動讓團隊完成設計思考。它們的角色比較像一張可延伸、可共編、可保存脈絡的數位白板，讓主持人把方法放進正確的位置。
我的判斷是，工具選錯通常不是最大問題，真正會讓工作坊失焦的是畫布太多、指令太模糊、每個階段沒有明確產出。白板越自由，主持規則越要清楚。
Miro vs FigJam：設計思考工作坊該選哪一個？
Miro 適合跨部門、流程複雜、需要長時間沉澱的設計思考工作坊；FigJam 適合設計團隊、產品團隊快速共創，並銜接 Figma 後續設計流程。選擇工具時，應看團隊組成、工作坊目的與最後產出。
Miro 適合什麼團隊？
Miro 比較適合參與者來自產品、行銷、營運、客服、主管層等不同職能的工作坊。它的優勢在於大型白板、模板彈性、流程圖與複雜資料整理，適合處理服務流程、商業流程、利害關係人地圖與長週期專案。
如果一場工作坊需要從訪談摘要一路收斂到策略方向，Miro 通常比較穩。它不一定比較「設計」，但更像跨部門會議室。
FigJam 適合什麼團隊？
FigJam 適合已經使用 Figma 的設計、產品與前端團隊。它的互動門檻低，便利貼、投票、圖章、簡單流程圖都容易上手，適合快速發想、設計前期共創、使用者流程討論與設計交接前的釐清。
如果後續會進 Figma 做 wireframe、UI 或 prototype，FigJam 的流程銜接會很順。對新手講師來說，它也比較容易在短時間內帶參與者進入狀況。
一分鐘決策表：依團隊、目的、產出選工具
| 判斷條件 | 優先選 Miro | 優先選 FigJam |
|---|---|---|
| 團隊型態 | 跨部門、多人、多利害關係人 | 設計、產品、前端密集協作 |
| 工作坊複雜度 | 需要整理大量資料與流程 | 需要快速共創與即時討論 |
| 後續產出 | 策略方向、服務藍圖、流程改善 | 設計需求、使用者流程、Figma 前置討論 |
| 參與者熟悉度 | 可接受較完整的白板結構 | 需要低門檻、容易互動 |
| 主持重點 | 控管大型議題與分組成果 | 讓團隊快速動手、快速收斂 |
同理階段：用 Miro / FigJam 收集使用者觀察與訪談洞察
同理階段要把使用者的行為、情緒、痛點與需求假設整理出來。Miro 和 FigJam 最適合用來放訪談筆記、同理心地圖、使用者旅程地圖，讓團隊先看見事實，再討論解法。
同理心地圖欄位：看見、聽見、想法、痛點、需求
同理心地圖適合在訪談後快速整理使用者狀態。主持人可以先請參與者把原始觀察寫成便利貼，再分類到不同欄位。
| 欄位 | 填寫重點 | 範例方向 |
|---|---|---|
| 看見 | 使用者在情境中接觸到什麼 | 介面、流程、他人行為、環境限制 |
| 聽見 | 使用者受到哪些說法影響 | 同事建議、客服回覆、主管要求 |
| 想法 | 使用者心中在意什麼 | 擔心出錯、想節省時間、怕被責備 |
| 痛點 | 阻礙使用者完成任務的問題 | 資訊分散、步驟太多、不知道下一步 |
| 需求 | 可被設計回應的期待 | 需要更清楚的提示、更快的確認方式 |
使用者旅程地圖欄位：情境、行為、接觸點、痛點、機會
使用者旅程地圖適合處理一段完整流程，例如報名課程、申請服務、完成購買、內部申請表單。Miro 適合畫較長的服務旅程，FigJam 適合快速拉出前期流程與討論節點。
建議欄位包含：情境、使用者行為、接觸點、當下痛點、情緒變化、改善機會。不要急著把每個痛點都變成產品功能，先找出哪個節點最影響使用者完成任務。
主持提醒：先收斂觀察，不要太早跳解法
同理階段最常見的失誤，是參與者看到一張便利貼就開始提方案。主持人應要求每個人先用觀察語句描述，例如「使用者在付款前找不到運送資訊」，不要直接寫「新增 FAQ」。
我會把這一段看得很嚴，因為太早進入解法，後面的定義與發想只是在替第一個直覺補理由。
定義階段：用白板把零散洞察收斂成核心問題
定義階段要把同理階段的零散洞察，轉成清楚的問題句與設計挑戰。適合使用親和圖、5W2H 和 How Might We，讓團隊知道要解的問題是什麼、範圍到哪裡。
親和圖：把便利貼依主題群組
親和圖的做法，是先把所有觀察便利貼放在白板上，再由參與者共同拖曳分群。常見分群方式包括流程節點、痛點類型、使用者角色、情緒狀態與任務阻礙。
主持人不應一開始就替大家命名群組。比較好的做法是先讓相似便利貼自然靠近，再請團隊為每群下一個簡短標籤，例如「資訊不透明」、「等待時間焦慮」、「責任歸屬不清」。
5W2H：把問題邊界說清楚
| 欄位 | 定義問題時要問的事 |
|---|---|
| Who | 主要受影響的使用者是誰 |
| What | 使用者卡在哪個任務或流程 |
| When | 問題發生在什麼時機 |
| Where | 問題出現在什麼接觸點或場景 |
| Why | 造成痛點的可能原因是什麼 |
| How | 使用者目前如何處理或繞過問題 |
| How much | 問題影響的程度、頻率或成本如何描述 |
How Might We 問題句模板
How Might We 適合把負面痛點轉成可發想的設計挑戰。中文工作坊可以寫成「我們可以如何幫助某類使用者，在某個情境下，更順利地完成某個任務？」
- 我們可以如何幫助新使用者，在第一次設定帳號時，更清楚知道下一步要做什麼？
- 我們可以如何幫助客服人員，在處理重複問題時，更快找到一致的回覆依據？
- 我們可以如何幫助學生，在分組討論時，更容易說出自己的觀察與想法？
發想階段：用 Miro / FigJam 讓點子變多，也能被收斂
發想階段的目標不是找出唯一答案，而是先產生多種可能方案，再用清楚規則收斂。Miro 和 FigJam 可以支援腦力激盪、Crazy 8s、六頂思考帽、點投票與影響力／可行性矩陣。
發散工具：腦力激盪、Crazy 8s、六頂思考帽
| 方法 | 適合情境 | 白板操作方式 |
|---|---|---|
| 腦力激盪 | 需要大量產生初步點子 | 每人用便利貼寫點子，先不評論 |
| Crazy 8s | 需要逼出不同方向 | 在八格區塊內快速畫或寫八個方案 |
| 六頂思考帽 | 團隊討論容易偏向單一角度 | 依事實、風險、效益、創意等角度輪流補充 |
收斂工具：點投票、影響力／可行性矩陣
點投票適合快速篩出團隊有共識的點子，但它不能直接等於最終決策。票數高只代表目前被看見、被理解或被偏好，仍要放進影響力／可行性矩陣檢查。
| 收斂方式 | 適合判斷 | 注意事項 |
|---|---|---|
| 點投票 | 團隊初步偏好 | 每人票數要相同，避免主管先表態 |
| 影響力／可行性矩陣 | 優先順序 | 高影響、高可行可進入原型 |
| 假設清單 | 方案風險 | 把「我們相信」的前提列出來，後續測試 |
避免發想失控的主持規則
發想容易失控，通常是因為沒有時間盒、沒有問題句、沒有收斂標準。主持人應先把 How Might We 問題句放在白板最上方，並限制每一輪發想時間。
我建議發散與收斂分開做。發散時不批評，收斂時不再補新點子。這條規則看似普通，但能避免會議變成少數人辯論。
原型階段：用 FigJam 或 Miro 快速做低保真方案
原型階段不一定要做完整 UI 畫面，而是把方案變成可討論、可測試、可修改的草稿。Miro 適合服務流程與商業流程原型，FigJam 適合設計前期流程與 Figma 接續。
Miro 適合服務流程與商業流程原型
當方案牽涉多個角色、部門、接觸點或後台流程時，Miro 更適合做服務藍圖、流程圖、利害關係人地圖與營運流程草圖。這類原型的重點不是畫面精細，而是讓大家看懂流程如何運作。
FigJam 適合設計流程前段與 Figma 接續
FigJam 適合做使用者流程、低保真 wireframe、頁面區塊草圖與設計前討論。當團隊已經在 Figma 裡做介面，FigJam 可以作為需求釐清和設計共識的前置區。
原型做到什麼程度就可以測試？
| 測試目的 | 原型程度 | 適合工具 |
|---|---|---|
| 確認流程是否合理 | 流程圖、故事板 | Miro、FigJam |
| 確認使用者是否理解任務 | 低保真 wireframe | FigJam、Figma |
| 確認服務交付是否可行 | 服務藍圖、角色分工圖 | Miro |
| 確認文案或資訊順序 | 頁面架構草圖 | FigJam |
測試階段：用白板整理回饋、判斷下一步
測試階段的價值，是把使用者回饋轉成可判斷的下一步，而不只是收集意見。Miro 和 FigJam 可以用來建立測試紀錄表、回饋分類區、假設驗證區與修正優先順序。
測試紀錄表欄位
| 欄位 | 填寫內容 |
|---|---|
| 測試任務 | 請使用者完成的具體任務 |
| 觀察到的行為 | 使用者實際做了什麼，而非團隊解讀 |
| 使用者原話 | 關鍵語句，可保留原本用字 |
| 卡住的位置 | 流程、畫面、資訊或服務接觸點 |
| 對應假設 | 這個回饋驗證或推翻哪個假設 |
| 下一步 | 修改、保留、補測或回到定義 |
把回饋分成問題、建議、疑問、風險
使用者回饋不要全部混在一起。問題是使用者真的卡住，建議是使用者提出的解法，疑問是理解不足，風險是團隊需要進一步確認的假設。
這個分類很重要，因為使用者提出的建議不一定要照做，但使用者卡住的位置通常不能忽略。
何時回到定義？何時進入下一版原型？
如果測試回饋顯示使用者根本不認同問題、情境判斷錯誤，應回到定義階段。若問題成立，但方案中的流程、文案、接觸點不清楚，則進入下一版原型。
判斷標準可以很務實：問題不對，回定義；問題對但方案不順，改原型；方案可行但細節不清，補測局部。
2 小時、半天、一天工作坊流程怎麼排？
設計思考工作坊的時間安排，應依產出物決定。2 小時適合釐清問題與初步發想，半天可從同理走到方案收斂，一天才比較適合包含原型與初步測試安排。
2 小時版：適合快速釐清問題與發想
| 時間 | 活動 | 產出物 |
|---|---|---|
| 15 分鐘 | 說明目標與白板操作 | 共同問題範圍 |
| 30 分鐘 | 整理既有觀察與痛點 | 便利貼洞察 |
| 25 分鐘 | 親和圖分群 | 痛點群組 |
| 20 分鐘 | 撰寫 How Might We | 問題句 |
| 20 分鐘 | 快速發想與點投票 | 優先點子 |
| 10 分鐘 | 確認下一步 | 負責人與後續行動 |
半天版：適合從同理到方案收斂
半天版可以安排約 3 到 4 小時，適合產品探索、內部流程改善、教育課堂專題。建議包含同理心地圖、親和圖、How Might We、腦力激盪與影響力／可行性矩陣。
這種長度不適合塞太多模板。主持人應保留討論時間，讓團隊真正理解使用者痛點，而不是一路填表。
一天版：適合包含原型與初步測試
| 階段 | 活動 | 產出物 |
|---|---|---|
| 上午前段 | 同理整理、旅程地圖 | 痛點與機會點 |
| 上午後段 | 親和圖、5W2H、HMW | 問題定義 |
| 下午前段 | 發想、投票、矩陣收斂 | 候選方案 |
| 下午中段 | 低保真原型或服務藍圖 | 可測試草稿 |
| 下午後段 | 內部測試或測試計畫 | 回饋紀錄與下一輪假設 |
免費模板怎麼準備？設計思考工作坊必備畫布清單
設計思考模板應服務工作坊產出，不是越多越好。最實用的模板包括同理心地圖、使用者旅程地圖、How Might We、點子評分表、原型草圖與測試紀錄表。
五階段必備模板總表
| 階段 | 模板 | 功能 | 建議欄位 |
|---|---|---|---|
| 同理 | 同理心地圖 | 理解使用者狀態 | 看見、聽見、想法、痛點、需求 |
| 同理 | 使用者旅程地圖 | 找出流程痛點 | 情境、行為、接觸點、痛點、機會 |
| 定義 | How Might We | 轉換設計挑戰 | 使用者、情境、任務、期待改善 |
| 發想 | 點子評分表 | 篩選方案 | 點子、影響力、可行性、風險、下一步 |
| 原型 | 故事板或流程草圖 | 具象化方案 | 步驟、角色、接觸點、預期反應 |
| 測試 | 測試紀錄表 | 整理回饋 | 任務、觀察、原話、問題、決策 |
新手工作坊不要放太多模板
新手工作坊最容易犯的錯，是把白板做得像工具大全。模板太多會讓參與者忙著理解欄位，反而忘記討論使用者與問題。
若時間只有 2 小時，同理心地圖、HMW、點子投票通常已足夠。若時間到半天以上，再加入旅程地圖、評分矩陣與測試紀錄表。
模板欄位可直接複製到 Miro / FigJam
- 同理心地圖：看見、聽見、想法、痛點、需求、待確認假設
- 使用者旅程地圖：階段、情境、行為、接觸點、情緒、痛點、機會
- How Might We：我們可以如何幫助、使用者、情境、任務、期待結果
- 點子評分表：點子名稱、解決的痛點、影響力、可行性、風險、是否進入原型
- 測試紀錄表：測試任務、使用者反應、觀察事實、使用者原話、判斷、下一步
本文不深入比較的工具：Notion、ChatGPT、Canva、實體牌卡
Notion、ChatGPT、Canva 和實體牌卡都能輔助設計思考，但不適合作為這篇工作坊指南的主軸。它們可以幫忙整理、記錄、視覺化或暖身，不能取代主持人引導與團隊共創。
AI 可輔助整理，不應代替使用者洞察
ChatGPT 可以協助整理訪談摘要、改寫 HMW 問題句、歸納便利貼主題，但它不能替團隊完成同理。使用者洞察必須來自觀察、訪談、測試與實際情境。
我的建議是，AI 可以放在工作坊前後使用，工作坊中則應謹慎。若參與者把 AI 生成內容當成使用者真實回饋，問題定義會很快失真。
Notion 適合沉澱文件，不適合即時共創主場
| 工具 | 可輔助用途 | 限制 |
|---|---|---|
| Notion | 整理工作坊紀錄、決策、後續任務 | 不適合大量便利貼即時移動與共創 |
| ChatGPT | 摘要、改寫、分類、產生問題句草稿 | 不能代替使用者研究與現場判斷 |
| Canva | 整理簡報、輸出視覺化成果 | 不適合作為設計思考白板主場 |
| 實體牌卡 | 暖身、引導討論、破冰 | 不容易保存完整數位脈絡 |
設計思考有哪些方法？
設計思考常用方法包括同理心地圖、使用者旅程地圖、親和圖、5W2H、How Might We、腦力激盪、Crazy 8s、原型設計與使用者測試。選方法時應回到當下任務：理解問題、定義問題、產生方案、做出原型或驗證假設。
設計思考五步驟分別適合用哪些工具？
同理階段適合同理心地圖與使用者旅程地圖；定義階段適合親和圖、5W2H 和 How Might We；發想階段適合腦力激盪、Crazy 8s、點投票；原型階段適合流程草圖、故事板、低保真 wireframe；測試階段適合測試紀錄表與回饋分類表。
Miro 和 FigJam 哪個比較適合設計思考工作坊？
Miro 較適合跨部門、複雜流程、服務設計與策略型工作坊；FigJam 較適合設計團隊、產品團隊、快速共創與 Figma 流程銜接。若參與者多、資料多、流程長，優先考慮 Miro；若重點是快速討論與設計前置協作，優先考慮 FigJam。
沒有設計背景的人可以用 FigJam 跑工作坊嗎？
可以。FigJam 的便利貼、投票、連線與簡單圖形功能門檻低，適合沒有設計背景的參與者。但主持人仍要先準備好畫布、範例便利貼與清楚指令，避免大家一進白板就不知道要做什麼。
設計思考工作坊一定要用線上白板嗎？
不一定。實體工作坊可以使用白板、便利貼、紙張與牆面完成。線上白板的優勢在於遠端協作、保存紀錄、複製模板、快速投票與會後整理。若團隊成員分散，或成果需要長期追蹤，Miro 和 FigJam 會更方便。
同理心地圖和使用者旅程地圖差在哪？
同理心地圖聚焦單一使用者在某個情境下的看法、想法、痛點與需求；使用者旅程地圖聚焦一段流程中的行為、接觸點、情緒與痛點。前者適合理解人，後者適合理解流程。
How Might We 問題句要怎麼寫？
How Might We 可以寫成「我們可以如何幫助某類使用者，在某個情境下，更順利地完成某個任務？」好的 HMW 問題句要夠明確，能引導發想；也要保留空間，不能一開始就指定唯一解法。
發想階段點子太多時，該怎麼收斂？
可以先用點投票找出團隊關注的點子，再用影響力／可行性矩陣排序。若點子仍然太多，主持人可要求每個點子對應一個明確痛點，無法對應痛點的先暫停處理。
原型階段一定要做出 UI 畫面嗎？
不一定。原型可以是流程圖、故事板、服務藍圖、低保真 wireframe 或話術草稿。只要能讓團隊測試關鍵假設，就可以作為原型。UI 畫面只是在需要驗證介面理解時才必要。
設計思考可以用在教育課堂或內部流程改善嗎？
可以。教育課堂可用設計思考訓練學生觀察問題、提出方案與測試想法；內部流程改善可用來找出跨部門卡點、重新定義服務流程、設計更好的申請或交付機制。關鍵是把使用者換成學生、員工、客服、主管或其他實際角色。
ChatGPT 可以幫忙做設計思考工作坊嗎？
ChatGPT 可以輔助摘要訪談、分類便利貼、改寫問題句、產生發想提示，但不應取代使用者觀察與團隊討論。設計思考的核心仍是理解真實情境，並透過共創做出可測試的方案。
2 小時設計思考工作坊最少要產出什麼？
2 小時工作坊最少應產出一組清楚問題句、幾個優先痛點、初步點子清單與下一步行動。若時間有限，不建議硬做完整五步驟，應把重點放在問題釐清與可執行的後續安排。