設計思考五步驟是什麼？
設計思考五步驟是同理 Empathize、定義 Define、發想 Ideate、原型 Prototype、測試 Test。這套設計思考流程的重點，是先理解使用者情境與痛點，再收斂問題、產生解法、做出可測試版本，最後用真實回饋持續迭代。它不是固定直線流程，團隊常會在測試後回到定義、發想或原型階段修正方向。
五步驟快速對照表
| 步驟 | 核心問題 | 主要任務 | 產出物 |
|---|---|---|---|
| 同理 Empathize | 使用者真正遇到什麼情境？ | 訪談、觀察、整理行為與情緒 | 訪談筆記、同理心地圖、使用者旅程地圖 |
| 定義 Define | 團隊到底要解哪個問題？ | 找洞察、整理痛點、寫問題陳述 | POV、問題陳述、需求優先序 |
| 發想 Ideate | 有哪些可能的解法？ | 擴大點子量，再篩選可驗證方向 | 解法清單、優先解法、HMW 發想題 |
| 原型 Prototype | 怎麼用低成本把想法變成可測試版本？ | 製作紙本、流程、腳本或線框稿 | 低保真原型、服務腳本、流程圖 |
| 測試 Test | 使用者實際使用後有什麼回饋？ | 觀察行為、收集回饋、修正假設 | 測試紀錄、修正方向、下一輪假設 |
設計思考不是先想解法，而是先理解人
設計思考最容易被誤用的地方，是團隊一開始就討論功能、版面或活動方案。真正有用的設計思考，會先把焦點放回使用者：他在什麼情境下卡住、為什麼卡住、目前如何繞路解決、哪些情緒會影響決策。我的判斷是，流程本身不難，難的是團隊願不願意暫停自己的答案，先承認問題可能還沒被看清楚。
第一步：同理 Empathize，理解使用者真正的情境與需求
同理階段要解決的問題，是團隊對使用者理解太少，卻太快假設需求。這一步要透過訪談、觀察與情境整理，了解使用者的行為、痛點、情緒與決策因素，產出訪談筆記、同理心地圖或使用者旅程地圖。
同理階段要收集哪些資訊？
同理不是問使用者「你想要什麼功能」，而是理解他如何做決策、在哪裡停住、什麼情況會放棄。好的同理資料通常包含下列幾類：
- 使用者的角色、目標與任務情境。
- 完成任務時的實際行為，而不只聽他描述理想狀態。
- 過程中的卡點、情緒、猶豫與替代做法。
- 影響決策的資訊來源、限制條件與時間壓力。
- 使用者自己說不清楚，但從行為中看得出的矛盾。
可問問題包含：「你上次遇到這個問題時，第一步做了什麼？」、「當時讓你最猶豫的是什麼？」、「你最後為什麼選這個做法？」不建議問：「你會不會想要我們做一個新功能？」這種問法會把使用者推進假設好的答案裡。
常用工具：訪談、觀察、同理心地圖、使用者旅程地圖
| 工具 | 適合用途 | 可產出內容 |
|---|---|---|
| 使用者訪談 | 了解動機、痛點、決策原因 | 逐字重點、需求假設、代表性語句 |
| 觀察 | 看見使用者實際怎麼做 | 行為紀錄、卡點、繞路方式 |
| 同理心地圖 | 整理使用者所想、所感、所說、所做 | 情緒與行為洞察 |
| 使用者旅程地圖 | 看見整段流程中的接觸點與落差 | 流程痛點、改善機會點 |
常見錯誤：把使用者說出口的答案直接當需求
使用者說「我想要更快的流程」，不代表真正需求一定是縮短步驟；可能是資訊不清楚、付款信任感不足，或錯誤訊息讓他反覆確認。寫手、設計師或 PM 在這一步要多問一次「為什麼」，並把說出口的意見和觀察到的行為分開記錄。這個差異常常決定後面做出來的是有效解法，還是只是看起來合理的功能。
第二步：定義 Define，把資料整理成清楚的核心問題
定義階段要解決的問題，是把零散的訪談、觀察與痛點收斂成一個值得處理的核心問題。這一步的成果不是漂亮標語，而是清楚指出誰在什麼情境下遇到什麼困難，以及背後原因。
如何寫出好的問題陳述？
好的問題陳述要具體、可發想、可驗證，並且不要偷塞解法。可以用這個公式整理：
使用者在某個情境下，需要達成某個目標，但因為某個阻礙，導致某個痛點或結果。
例如：「第一次購買甜點禮盒的使用者，在結帳前需要確認到貨時間與保存方式，但因為資訊分散在不同頁面，導致他不敢完成付款。」這樣的寫法比「提升結帳體驗」更能引導團隊行動。
- 是否說清楚特定使用者？
- 是否有明確情境？
- 是否描述需求與阻礙？
- 是否還沒有指定解法？
- 是否能被後續原型與測試驗證？
POV 句型：誰在什麼情境下，需要什麼，因為什麼原因
POV 可以協助團隊把同理資料變成共同焦點。常用句型是：「某類使用者在某個情境下，需要某種協助，因為某個尚未被滿足的原因。」
範例：「忙碌的上班族在午休時間訂購生日蛋糕時，需要快速確認配送與付款是否可靠，因為他沒有時間反覆查詢客服。」這類句子能讓設計、行銷、客服與工程討論同一個問題，而不是各自解讀。
常見錯誤：問題定義太大、太模糊或已經偷塞解法
「讓品牌更受歡迎」太大，「改善使用者體驗」太模糊，「做一個提醒彈窗讓使用者結帳」則已經偷塞解法。比較好的定義會保留探索空間，例如：「使用者在付款前需要確認關鍵資訊，因為不確定配送與保存方式會增加放棄結帳的機率。」若問題定義和品牌定位有關，可以延伸參考 品牌定位策略，但在五步驟裡仍要回到可驗證的使用者問題。
如何把問題轉成 HMW 發想題？
HMW 是 How Might We 的縮寫，常譯為「我們可以如何」。它的作用是把問題陳述轉成可發想題目，讓團隊從抱怨或限制，轉向產生多種可能解法。好的 HMW 不能太窄，也不能太空。
HMW 的基本句型
| 來源問題 | HMW 句型 | 用途 |
|---|---|---|
| 使用者不確定配送時間 | 我們可以如何讓使用者在付款前更放心確認配送資訊？ | 引導資訊呈現、流程設計、客服支援等點子 |
| 新手不知道該選哪個方案 | 我們可以如何協助新手用較少判斷成本選到適合方案？ | 引導比較、推薦機制、說明方式 |
| 使用者覺得品牌不夠可信 | 我們可以如何在關鍵決策點降低使用者的不確定感？ | 信任訊號、案例、保障資訊 |
不好的 HMW 與好的 HMW 差在哪？
| 不好的 HMW | 問題 | 修正版 |
|---|---|---|
| 我們可以如何做一個彈窗提醒付款？ | 已經指定解法 | 我們可以如何在付款前提醒使用者確認關鍵資訊？ |
| 我們可以如何讓所有人都喜歡這個服務？ | 範圍太大，無法操作 | 我們可以如何讓第一次使用者更快理解服務價值？ |
| 我們可以如何改善體驗？ | 太模糊，沒有情境 | 我們可以如何降低使用者在結帳頁的猶豫感？ |
第三步：發想 Ideate，先擴大可能性，再篩選可行解法
發想階段要解決的問題，是團隊太快抓住第一個點子，忽略其他可能性。這一步要先大量產生解法，再依使用者價值、可行性、成本與驗證速度篩選出適合進入原型的方向。
發想階段的重點不是找唯一正解
發想初期先求量，暫時延後批判，讓團隊把直覺解法、反向解法、服務流程、內容溝通與介面調整都攤開。接著再收斂，挑出最值得驗證的幾個方向。太早追求正解，通常只會讓會議被職位最高或聲音最大的人主導。
- 先確認 HMW 題目。
- 設定短時間大量發想。
- 每個人先獨立寫點子，再一起分享。
- 合併相似解法。
- 用篩選標準選出要做原型的方案。
可用工具：腦力激盪、六頂思考帽、系統九宮格法
腦力激盪適合快速產生大量點子；六頂思考帽適合讓團隊從事實、風險、情緒、創意等不同角度看解法；系統九宮格法則適合把問題拆成不同場景或接觸點。工具不必一次全用，選能讓團隊跳脫慣性討論的方式即可。
如何篩選要進入原型的解法？
| 篩選標準 | 判斷問題 | 建議做法 |
|---|---|---|
| 使用者價值 | 這能直接改善痛點嗎？ | 優先處理最靠近核心問題的解法 |
| 可行性 | 短期內做得出可測試版本嗎？ | 避免一開始就選大型系統改造 |
| 成本 | 需要多少時間、人力與預算？ | 先選低成本可學習的方案 |
| 驗證速度 | 多久能拿到真實回饋？ | 優先選能快速測試假設的方案 |
第四步：原型 Prototype，用低成本方式把想法做出來
原型階段要解決的問題，是想法停留在口頭討論，無法被使用者理解或測試。原型可以是紙本、線框稿、流程圖、服務腳本或假頁面，重點是用低成本把假設做成可觀察的版本。
哪些東西可以算是原型？
| 原型形式 | 適合情境 | 可測試內容 |
|---|---|---|
| 紙本原型 | 早期介面或流程概念 | 資訊順序、操作理解 |
| 線框稿 | 網站、App、後台流程 | 版面結構、任務路徑 |
| 服務腳本 | 客服、門市、課程與工作坊 | 對話節點、服務承諾 |
| 流程圖 | 跨部門服務或結帳流程 | 卡點、責任分工、資訊落差 |
| 低保真假頁面 | 活動頁、產品頁、方案頁 | 訊息理解、行動誘因 |
原型要做到多完整？
原型完整度取決於要測什麼。若要測使用者是否理解付款資訊，線框稿或簡易頁面已足夠；若要測視覺溝通是否清楚，才需要加入較完整的版面與視覺層次，可延伸參考 廣告設計視覺原則。展示用原型追求說服利害關係人，測試用原型追求讓使用者做出反應。兩者目的不同，不宜混在一起評估。
常見錯誤：把原型做得太精緻，反而不敢改
原型太精緻會讓團隊投入過多時間，也會讓測試者不敢提出批評。更麻煩的是，團隊會開始捍衛作品，而不是檢查假設。早期原型應該故意保持可修改，讓錯誤便宜一點。這是設計思考很務實的地方：不是追求第一次就對，而是把學習成本壓低。
第五步：測試 Test，用真實回饋修正解法
測試階段要解決的問題，是團隊不知道解法是否真的有效。測試不是問使用者喜不喜歡，而是觀察他能否完成任務、在哪裡卡住、哪些回饋能支持下一輪修改、保留或放棄。
測試時應該觀察什麼？
測試時要看行為多於稱讚。使用者口頭說「很清楚」，但操作時反覆回上一頁，就代表設計仍有落差。建議觀察：
- 使用者是否理解任務目標。
- 第一眼注意到哪些資訊。
- 在哪個步驟停頓、猶豫或誤解。
- 是否能不靠提示完成任務。
- 回饋是針對真實痛點，還是個人偏好。
可問：「你剛才為什麼停在這裡？」、「你預期點下去會發生什麼？」不建議問：「你喜歡這個設計嗎？」因為喜歡不等於可用，也不等於會採取行動。
測試後如何決定要修改、保留或放棄？
| 測試結果 | 判斷方式 | 下一步 |
|---|---|---|
| 多數人卡在同一處 | 可能是流程或資訊架構問題 | 回到原型或定義階段修正 |
| 使用者能完成任務，但仍有疑慮 | 核心方向可行，信任或說明不足 | 保留主流程，補強資訊與提示 |
| 使用者根本不在意該問題 | 問題定義可能失準 | 回到同理與定義階段重新確認 |
| 回饋分歧很大 | 族群或情境可能混在一起 | 重新切分使用者與使用情境 |
常見錯誤：只找熟人測試，或只收集稱讚
熟人通常會給比較客氣的回饋，也可能太了解你的背景，無法代表真實使用者。測試應該盡量找接近目標族群的人，並記錄行為證據。失敗不代表設計思考失敗，反而代表團隊在投入大成本前找到修正方向。把失敗當作資料，流程才有價值。
設計思考五步驟的工具與產出物對照表
設計思考五步驟可以用「步驟、目的、工具、活動、產出物、常見錯誤」來管理。這張表適合產品會議、課程、工作坊或專案啟動時使用，讓每個階段都有清楚交付成果。
五步驟工具、產出物、常見錯誤總表
| 步驟 | 目的 | 常用工具 | 適合活動 | 產出物 | 常見錯誤 |
|---|---|---|---|---|---|
| 同理 | 理解使用者情境與痛點 | 訪談、觀察、同理心地圖 | 使用者訪談、情境紀錄 | 訪談筆記、旅程地圖 | 把使用者意見直接當需求 |
| 定義 | 收斂核心問題 | POV、痛點整理、優先排序 | 洞察歸納、問題陳述 | 問題陳述、需求優先序 | 問題太大或偷塞解法 |
| 發想 | 產生多種可能解法 | HMW、腦力激盪、六頂思考帽 | 點子發散、概念分類 | 解法清單、優先方案 | 太早批評或只討論第一個點子 |
| 原型 | 讓解法變成可測試版本 | 紙本原型、線框稿、服務腳本 | 快速製作、情境演練 | 低保真原型、流程圖 | 做得太精緻，導致不敢修改 |
| 測試 | 取得真實回饋並修正 | 使用者測試、回饋紀錄表 | 任務測試、訪談回饋 | 測試紀錄、下一輪假設 | 只問喜不喜歡或只找熟人 |
設計思考五步驟與雙鑽石模型差在哪？
設計思考五步驟是操作流程，雙鑽石模型是發散與收斂的思考地圖。五步驟告訴團隊每一階段要做什麼，雙鑽石則幫助團隊理解什麼時候要擴大探索，什麼時候要收斂決策。
五步驟是操作流程，雙鑽石是發散收斂地圖
雙鑽石通常把設計過程分成問題空間與解法空間：先發散理解問題，再收斂定義問題；接著發散尋找解法，再收斂成可執行方案。五步驟則更適合轉成會議、任務與交付成果。我的看法是，初學者先用五步驟比較不容易迷路，等團隊熟悉後，再用雙鑽石檢查自己是否太快收斂。
兩者如何對應？
| 雙鑽石階段 | 對應五步驟 | 團隊重點 |
|---|---|---|
| 探索問題 | 同理 | 擴大理解使用者與情境 |
| 定義問題 | 定義 | 收斂成核心問題陳述 |
| 發展解法 | 發想、原型 | 產生多種解法並做成可測試版本 |
| 交付與修正 | 測試 | 根據回饋決定修改、保留或放棄 |
設計思考一日工作坊可以怎麼安排？
設計思考工作坊可以依時間分成 3 小時快速版、半天實作版與一天完整版。時間越短，越需要縮小題目；時間越長，越能完整跑過同理、定義、發想、原型與測試。
3 小時快速版
| 時間配置 | 活動 | 產出物 |
|---|---|---|
| 30 分鐘 | 題目說明與使用者情境整理 | 初步痛點清單 |
| 40 分鐘 | 定義問題與 HMW | 問題陳述、HMW 題目 |
| 50 分鐘 | 發想與篩選 | 解法清單、優先方案 |
| 45 分鐘 | 快速原型 | 紙本或流程原型 |
| 15 分鐘 | 回饋與下一步 | 修正方向 |
半天實作版
半天版本適合內訓或專案啟動會議，可以加入簡短訪談資料、同理心地圖與一輪原型測試。建議把題目限制在單一流程或單一使用者任務，例如註冊、結帳、預約、客服回覆，而不是整個產品策略。
一天完整版
一天版本可以安排較完整的使用者資料整理、POV、HMW、分組發想、原型製作與交叉測試。若參與者包含 PM、設計、行銷、客服、業務與工程，產出會更接近實際落地條件。工作坊最大的風險不是時間不夠，而是題目太貪心，最後每一步都只做到表面。
設計思考案例：用電商結帳流程跑一次五步驟
電商結帳流程很適合示範設計思考五步驟，因為它同時涉及使用者信任、資訊理解、介面行動與付款決策。以下用台灣甜點電商的付款前離開問題，示範從同理到測試的走法。
案例背景：使用者常在付款前離開
某甜點電商發現使用者已加入購物車，卻常在付款前離開。團隊原本想直接加折扣，但同理階段發現，許多使用者不是嫌價格高，而是不確定到貨時間、保存方式與付款安全性。這時候若只做促銷，很可能沒有解到真正痛點。
從同理到測試的完整走法
| 步驟 | 案例做法 | 產出 |
|---|---|---|
| 同理 | 訪談首次購買者，觀察他們在結帳頁停留的位置。 | 發現配送、保存、付款信任是主要猶豫點。 |
| 定義 | 整理問題陳述：首次購買者在付款前需要確認關鍵資訊，因為資訊分散會降低信任。 | 核心問題與 HMW 題目。 |
| 發想 | 提出資訊摘要區、付款保障提示、配送日期選擇、常見問題折疊區等解法。 | 優先選擇資訊摘要區與付款保障提示。 |
| 原型 | 製作低保真結帳頁線框，加入配送、保存與付款說明。 | 可測試的結帳頁原型。 |
| 測試 | 請目標使用者完成購買任務，觀察是否仍反覆尋找資訊。 | 修正資訊順序，並檢查行動按鈕是否清楚，可參考 按鈕設計指南。 |
企業導入設計思考時，誰應該參與？
企業導入設計思考時，不應只讓設計部門參與。PM、設計、行銷、客服、業務與工程都能在五步驟中提供不同資訊，讓問題定義更準、解法更可行、測試回饋更接近真實營運條件。
不同角色在五步驟中的責任
| 角色 | 主要貢獻 | 對應步驟 |
|---|---|---|
| PM 或專案負責人 | 界定目標、協調資源、確認優先順序 | 定義、發想、測試 |
| 設計師 | 整理使用者洞察、製作原型、規劃測試 | 同理、原型、測試 |
| 行銷企劃 | 理解受眾語言、轉換溝通訊息 | 同理、發想、原型 |
| 客服 | 提供第一線抱怨、疑問與常見情境 | 同理、定義、測試 |
| 業務 | 補充購買疑慮、成交阻礙與客戶回饋 | 同理、定義、發想 |
| 工程 | 評估技術限制、開發成本與驗證方式 | 發想、原型、測試 |
小團隊也能做設計思考嗎？
小團隊可以做設計思考，但要縮小題目與交付物。兩三個人也能完成簡易訪談、問題陳述、HMW、紙本原型與快速測試。小團隊的優勢是決策快，風險是容易用自己的經驗代替使用者資料。只要願意找真實對象測試，就已經比關在會議室裡猜需求更接近答案。
常見問題
設計思考五步驟一定要照順序做嗎？
不一定。初學或工作坊可以照同理、定義、發想、原型、測試的順序跑，方便建立共同語言。但實務上常會回頭修正，例如測試後發現問題定義錯了，就要回到同理或定義階段重新整理。
設計思考的五個步驟分別是什麼？
五個步驟是同理 Empathize、定義 Define、發想 Ideate、原型 Prototype、測試 Test。同理理解使用者，定義收斂問題，發想產生解法，原型做出可測試版本，測試用回饋修正方向。
同理階段一定要做使用者訪談嗎？
不一定，但訪談是很常用的方法。若時間有限，也可以用客服紀錄、銷售回饋、現場觀察、使用者操作紀錄補充。不過只看內部意見不夠，至少要有一些來自真實使用者的行為或語句。
定義問題時，HMW 是什麼意思？
HMW 是 How Might We，意思是「我們可以如何」。它把問題陳述轉成可發想的題目，例如把「使用者不確定配送時間」轉成「我們可以如何讓使用者在付款前更放心確認配送資訊？」
發想階段要怎麼避免大家只討論同一個解法？
先讓每個人獨立寫點子，再一起分享，避免一開始就被某個方案帶走。也可以設定數量目標，例如每人先提出多個解法，最後再用使用者價值、可行性、成本與驗證速度篩選。
原型一定要做成產品或 App 畫面嗎？
不用。原型可以是紙本草圖、流程圖、服務腳本、線框稿、假頁面或簡短對話流程。只要能讓使用者理解並產生反應，就可以作為測試用原型。
測試失敗代表設計思考失敗嗎？
不代表。測試失敗通常代表團隊提早發現假設不成立，可以在投入更多成本前修正。設計思考重視迭代，測試的價值正是找出下一輪該改什麼。
設計思考和雙鑽石模型有什麼不同？
設計思考五步驟比較像操作流程，雙鑽石模型比較像發散與收斂的思考地圖。兩者可以搭配使用：同理與定義對應問題空間，發想、原型與測試對應解法空間。
設計思考和 Design Sprint 差在哪？
設計思考是一套較廣泛的問題解決流程，可以依專案調整時間與方法。Design Sprint 則是較固定節奏的短期驗證流程，常用來在幾天內聚焦問題、做原型並測試概念。若團隊剛開始學，先掌握五步驟會比較穩。
小團隊或個人可以使用設計思考嗎？
可以。小團隊或個人可以把流程縮小，例如訪談少量使用者、寫一個問題陳述、產生幾個解法、做低保真原型，再找目標對象測試。重點是不要只靠自己猜需求。
設計思考適合用在哪些情境？
適合用在使用者需求不清楚、跨部門對問題看法不同、產品或服務需要改善、課程與工作坊要設計活動流程、品牌或內容需要更貼近受眾情境時。若問題已經很明確，只需要執行既定方案，未必需要完整跑五步驟。
設計思考工作坊通常要多久？
常見安排有 3 小時、半天與一天。3 小時適合快速體驗，半天適合跑完基本發想與原型，一天可以更完整處理同理、定義、發想、原型與測試。時間越短，題目就要越聚焦。