設計思考五步驟完全指南：用同理心解決問題，打造使用者真正需要的產品
設計思考（design thinking）是一種以使用者為中心、用來定義並解決複雜問題的方法論，透過同理、定義、發想、原型、測試這五個動作反覆收斂，確保做出來的東西真的是使用者要的…
以使用者為中心的解題方法：設計思考的五步驟收斂迴圈
設計思考（design thinking）是一種以使用者為中心、用來定義並解決複雜問題的方法論，透過同理、定義、發想、原型、測試這五個動作反覆收斂，確保做出來的東西真的是使用者要的，避開設計師自己憑空想像。這套方法源自設計顧問公司 IDEO 與史丹佛大學 d.school 自 1990 年代起累積的實務研究與教學，目前已是全球創新專案常見的標準作業流程之一。真正決定成敗的，往往是前段有沒有把對的問題挖出來，後段發想與原型做得再精緻也補不回來。
重點先看：設計思考五步驟是一個發散與收斂交替的迴圈，會反覆折返；多數失敗的團隊，都把重心放在做原型，卻在錯誤的問題上燒資源。
很多人第一次接觸設計思考，都以為它是一套口號式的五步驟，照著做完就能交差。其實這是最普遍的誤解。五步驟只是骨架，重點在於發散與收斂之間的來回切換，而那個最容易被跳過的「定義（Define）」，正好就是整套方法的槓桿點。如果你想把這套方法用在網頁設計從零到一完整指南或任何產品開發上，先把這個觀念釐清，後面才不會白忙一場。
設計思考能跨領域存活，靠的是它處理問題的層次夠根本。它不問「這個功能怎麼做」，而是問「這個問題到底值不值得解」。這一點把它和所有技術導向的方法拉開距離。當一個團隊只會優化既有的功能、卻從不質疑功能本身的前提，他們再努力也只是把錯誤的方向執行得更完美。設計思考的價值，在於提供一套可以反覆演練的紀律，強迫團隊在動手之前先把「我們到底在為誰解什麼」這句話寫清楚，並且能用證據回答。
另一個常被忽略的前提是，設計思考處理的是「棘手問題」（wicked problems），也就是那些沒有單一正確答案、邊界定義模糊、解法會牽動整個系統的問題。改造一個城市的交通、重新設計一套醫療掛號流程、決定一個新產品該不該存在，都屬於這一類。面對這種問題，線性的「分析再執行」會失靈，因為問題本身會在你試圖解決它的過程中改變形狀。設計思考用迭代與原型來對抗這種不確定性，先做一個粗略版本去碰觸現實，再根據現實的回饋修正認知。
設計思考跟一般設計流程，到底差在哪裡
設計思考與一般設計流程最大的差別，在於起點完全相反。一般流程從「要做什麼」開始，設計思考則從「為誰做、解決什麼痛點」開始，順序顛倒就會做白工。它把使用者放在決策中心，先理解需求再動手設計，這也是為什麼它能跨領域套用，不限於UI 原型設計與 Wireframe 差異解析這類數位產品。
把視野拉大一點看，設計思考之所以被 IDEO 與史丹佛 d.school 推廣到全球，是因為它處理的核心難題是「確認自己解的是對的問題」，漂亮的成品只是附帶結果。你回想一下自己經手過的專案，有多少時間是花在改一個其實根本沒人在乎的功能？實務上常見的情況是，團隊裡為數不少的 rework，回頭追都能追到前段沒把問題定義清楚。這也是為什麼有經驗的人會建議，在動手做任何顧客旅程地圖繪製指南之前，先花時間把使用者的真實處境摸透。
| 比較項目 | 一般設計流程 | 設計思考 |
|---|---|---|
| 起點 | 要做什麼功能 | 為誰做、解決什麼痛點 |
| 決策中心 | 設計師或主管的判斷 | 使用者的真實需求 |
| 流程特性 | 線性、走完就收工 | 發散與收斂交替的迴圈 |
| 失敗通常出現在哪 | 執行細節 | 前段問題定義 |
| 適用範圍 | 多半限設計部門 | 產品、服務、政策、流程皆可 |
換個角度想，設計思考之所以有用，在於它強迫你慢下來，把「以為自己懂」的問題重新檢驗一次，至於它夠不夠創新，反倒是附帶結果。這對做Persona 人物誌建立方法或品牌官網設計全攻略的人特別有感，因為這兩件事最容易在沒有依據的情況下空想。
判斷一個團隊有沒有真正在跑設計思考，有兩個外部可觀察的訊號。第一個是它能不能在會議裡容許「我還不知道」這句話存在。線性流程容不下不確定性，任何人說「還不確定」都會被當成拖延；設計思考反而把這句話當成輸入，把不確定轉成一個需要被驗證的假設。第二個訊號是它願不願意公開承認自己上一輪的假設錯了。一個每次都做對、從不退回前段的團隊，多半是在事後把流程套上去，真正的設計思考一定會留下「我們本來以為 A，測完才發現是 B」的修正痕跡。
設計思考、敏捷、精實創業：三套常被搞混的方法怎麼選
很多人把設計思考、敏捷開發（Agile）、精實創業（Lean Startup）當成同一件事混著用，其實它們解的是不同階段的問題，硬要互相取代反而會打架。設計思考處理的是「我們到底該解什麼題」，發生在產品還沒成形之前；精實創業處理的是「我猜的這個解法值不值得做下去」，靠最小可行產品快速驗證商業假設；敏捷開發處理的是「已經知道要做什麼，怎麼把工程產出切小段快速交付」。三者可以串成一條時間軸：先用設計思考定義問題，再用精實創業驗證方向，最後用敏捷維持工程節奏。
| 方法 | 主要回答的問題 | 核心產出 | 最不擅長 |
|---|---|---|---|
| 設計思考 | 為誰解、解什麼痛 | 問題陳述、使用者洞察、原型 | 長期工程交付節奏 |
| 精實創業 | 這個方向值不值得投 | 最小可行產品、學習指標 | 前期深度需求探索 |
| 敏捷開發 | 怎麼把確定的東西快速做出来 | 可發布的功能增量 | 質疑功能本身是否該存在 |
實務上最危險的組合，是團隊跳過設計思考與精實創業，直接用敏捷去衝一個沒有人驗證過需求的功能。衝刺速度越快、迭代週期越短，只代表你用更快的節奏浪費工程資源。敏捷本身不會告訴你「這個 backlog 項目根本不該存在」，那是設計思考與精實創業的職責。把三者的分工想清楚，你才會知道什麼時候該停下衝刺、退回去做使用者研究。如果你的團隊正在這條軸線上卡關，行銷策略制定完整步驟與SWOT 分析策略工具教學能幫你把方向這一步補回來。
第一步 同理（Empathize）：挖出使用者說不清楚的痛點
同理是設計思考的第一個動作，目的是站在使用者立場去理解他的需求、情緒與困難，靠觀察、訪談、問卷、實際體驗這四種方法蒐集第一手資料，挖出使用者自己都說不清楚的潛在痛點。它的終點要落在看到使用者實際做了什麼，問卷收完只是中途。說到底，我們能不能真正讀懂另一個人心裡在想什麼，這個他心問題在行銷研究裡同樣揮之不去，也因此才需要靠觀察行為，光聽他怎麼說遠遠不夠。
說實在的，同理這一步很多人會做成「發個問卷、收幾十份回來就當結論」。問題是問卷只能告訴你使用者「說」了什麼，卻很難捕捉他們「做」了什麼。真正有價值的洞察，往往藏在那些使用者自己也講不清楚的猶豫瞬間。所以比較穩當的做法是，至少把一半的研究心力放在一對一訪談與現場觀察，問卷只當成量化補充。如果你手上有UIUX 設計師常用的 ChatGPT 指令，可以請 AI 協助整理訪談逐字稿、把重複出現的關鍵字標出來，但千萬不要用 AI 取代真實的使用者接觸。這條界線現在尤其值得守住，畢竟有調查顯示大約 94% 的行銷人員計畫在內容產製流程（包含部落格文章）裡使用 AI [來源：〈HubSpot Marketing Statistics (citing HubSpot State of Marketing Report, 2026)〉〈https://www.hubspot.com/marketing-statistics〉〈2026〉]，工具普及反而讓「用 AI 跑虛擬使用者訪談」這類省略真實接觸的捷徑變得更誘人，也更危險。
- 觀察行為：到使用者的實際場域，看他怎麼操作、卡在哪、臉上有什麼表情，親眼看到的比他事後轉述的更可靠。
- 一對一訪談：用開放問句引導對方說故事，例如「上次遇到這個狀況，你後來怎麼處理？」，避免封閉式的誘導。
- 問卷量化：當你需要驗證某個假設在多大比例的人身上成立時才用，不要把它當成唯一來源。
- 親身實際體驗：自己走一次使用者的流程，很多設計師做完這步才驚覺原本的流程有多不順。
深度訪談的開場腳本與問題設計
一對一訪談最容易在開場五分鐘就定生死。如果第一個問題是「你覺得我們的產品哪裡不好用」，受訪者會進入評價模式，開始講禮貌話；如果第一個問題是「最近一次你遇到這件事是什麼時候，當時的狀況是什麼」，受訪者會進入回憶模式，講出真實情境。把問句從「評價」改成「回憶事件」，是訪談品質的第一個分水嶺。
- 暖場問句：先讓對方講一件最近發生、和主題有關的小事，目的是讓他習慣開口講細節，意見留到後面再問。
- 情境回顧：「上一次你做這件事是什麼時候？把那次的過程從頭說一次。」追問他停頓、皺眉、繞路的瞬間。
- 追問細節：當對方說「還好」「差不多」這類模糊詞，立刻追「你說的還好是什麼意思？可以舉一個具體的例子嗎？」
- 避免為何、多問如何：「你當時為什麼這樣做」常逼出事後合理化的答案；「你當時是怎麼做的」能挖出真實行為。
- 沉默是工具：對方講完一段，多停三秒不要接話，很多人會在這三秒裡補出最有價值的那一句。
這一步做完，你手上應該有一疊使用者語錄、行為觀察筆記、痛點清單。這些就是交給下一個定義階段的原料。如果你想把這些資料整理成結構化的使用者輪廓，可以把零散的觀察收斂成可討論的對象，例如寫成具體的人物誌。想進一步把輪廓做得更可用，可以參考這篇Persona 人物誌介紹，了解用途與常見誤區。同理做不扎實，後面讀再多自學資源也很難落地。
第二步 定義（Define）：用 POV 句型鎖定真正要解的題
定義階段把同理蒐集到的零散資訊收斂成一句明確的問題陳述，最常用的工具是 POV（Point of View）句型，定義錯了後面四步全白做。它真正要做的是逼團隊對「到底要解什麼」達成共識，把資料彙整成報告只是表象。和 POV 思路相近的，是行銷領域的JTBD 用途理論，同樣把焦點放在使用者「雇用」這個產品想完成什麼事，產品本身的功能反而是附帶。
這是整套設計思考裡最關鍵、卻也最常被跳過的一步。很多團隊同理做完，就直接跳進發想，因為「討論問題陳述很無聊、好像沒有產出」。但問題就在這裡：定義偏了，發想的方向就跟著偏，團隊會在錯誤的前提下狂做原型，燒掉一堆工程資源才發現解錯題。史丹佛 d.school 的教材把定義稱為整個流程的樞紐，實戰裡這句話被驗證過的次數多到數不清。
POV 的三段式句型是這樣的：有一個（用戶特徵）的人，需要（用戶需求），因為對他來說（用戶見解）很重要。舉個例子：有一個愛運動的人，需要一個提供多種器材訓練的健身房，因為對他來說維持健康的體態很重要。這句話看似簡單，但它強迫你同時回答三件事：為誰做、做什麼、為什麼重要。任何一段寫不出來，就代表前段的同理還沒做完。
| POV 三段 | 要回答的問題 | 常見錯誤 |
|---|---|---|
| 用戶特徵 | 這個人是誰、處在什麼情境 | 寫成「所有使用者」而沒有聚焦 |
| 用戶需求 | 他需要什麼（需求，不是解法） | 把解法寫進去，例如「需要一個 App」 |
| 用戶見解 | 為什麼這件事對他重要 | 只寫功能好處，沒有動機 |
區分「問題」與「解法」：定義階段最關鍵的判斷
POV 寫壞，九成是因為把解法偷渡進了需求段。一個簡單的檢驗方法：把你寫出來的「需求」拿掉，換成任何一個同類產品的名字，如果句子仍然成立，那你寫的是問題；如果句子立刻變得荒謬，那你寫的是解法。舉例來說，「需要一個能在手機上記帳的 App」是解法，因為你把「手機」「記帳」「App」三個實作選擇都焊死了；改成「需要在花錢的當下就能記下這筆支出，以免事後忘記」，才是問題，因為它留下了紙本、語音、自動扣款等各種解法的空間。發想階段能不能蹦出跳脫框架的點子，完全取決於你在這裡有沒有把解法的門留開。
另一個常見的失誤，是把使用者的「要求」當成「需求」。使用者說「我想要一個更快的搜尋框」，這是要求；真正的需求可能是「我想要在還沒離開當下這個畫面之前就找到我要的東西」。要求帶著解法，需求只帶著處境。把要求翻譯成需求，是定義階段最值得花時間磨的動作，磨不出來就回頭補同理。
問題定義偏了，團隊就算把Landing Page 銷售頁製作教學或CTA 行動呼籲按鈕設計指南做得再漂亮，也只是在一個錯誤的前提上堆疊細節。把這個觀念再放大一層，產品到底要在哪個賽道上被理解，牽涉到品類策略的選擇，品類定錯了，再好的設計也很難被市場看見。
第三步 發想（Ideate）：點子的數量比可行性更先出場
發想階段用腦力激盪先把量衝出來，再搭配 HMW（How Might We，我們如何）提問法把問題拆成可回答的小問題，規則是先不批評、先不論可行性，任何點子都先寫下來再說。它的核心是「量先於質」。
腦力激盪最常見的死法，是開會開假的。大家圍著白板，第一個人提了點子，第二個人馬上接「這個不可行啦」，於是後面的人就開始自我審查，會議結束時白板上只剩下三個安全但無聊的方案。IDEO 在其 Design Kit 公開教材裡明確列出幾條腦力激盪守則，目的就是排除這種扼殺點子的行為。發想的品質取決於團隊有沒有心理安全感，怕被否決的成員會自動把有風險的好點子吞回去，這跟成員聰不聰明關係反而沒那麼大。
守則的核心其實只有一句話：把「寫下來」和「要不要做」強制分開。下表把四條守則對照成「這一條在擋掉什麼」，比起單純列點，更能看出它們其實是在對抗同一組扼殺點子的反射動作。
| 發想階段的守則 | 它在擋掉的反射動作 | 留到哪個階段處理 |
|---|---|---|
| 任何點子先寫下來（白板、便利貼、記事本） | 在腦袋裡自我過濾、只提安全牌 | 收斂階段統一分類 |
| 禁止「但是」「不可行」 | 第一時間否定別人，逼出事後合理化 | 收斂階段的批判式篩選 |
| 具體稱讚好點子 | 團隊不敢冒險、心理安全感不足 | 全程維持 |
| 先不論可行性 | 太早用工程現實綁死想像空間 | 收斂階段再篩可行性 |
HMW 拆解法與收斂投票：把亂點子變成可執行方向
HMW 提問法是發想的最佳搭檔，它把一個大問題拆成多個「我們如何＿＿？」的開放問句。例如你定義出來的問題是「改善網站使用體驗」，就可以拆成：我們如何讓使用者更快找到他要的商品？我們如何降低結帳時的放棄率？我們如何讓首次訪客在三秒內理解這個網站在賣什麼？每一個 HMW 問句背後，都可以長出一整排對應的點子，這比直接問「大家有什麼想法」有效得多。如果你正在做網頁版面設計與 RWD 排版攻略或響應式網頁設計 RWD 觀念，HMW 能幫你把「做好 RWD」這種空泛目標拆成可執行的小問題。
HMW 拆得越細越好，一個大問題通常可以拆出五到十個子問句。拆完之後做一輪投票收斂：每人發三張點數貼紙，貼在他認為最有潛力的 HMW 上，得票最高的兩三個就是這一輪要深入發想的標的。這個動作看起來草率，但它的價值在於把「全場七嘴八舌」收斂成「全場聚焦在兩三題」，避免發想能量被攤薄。投票前先給五分鐘靜默書寫，讓內向成員有時間把點子寫下來再貼牆，這個細節會明顯拉高點子的多樣性。
發想的順序很簡單：先發散衝量，量越多越好；再分類整理，把相似點子群聚起來，挑出有潛力的方向收斂。不要在發散階段就想收斂，那是兩種截然不同的思考模式，混在一起只會兩頭空。這個原則同樣適用於內容行銷策略打造方法與行銷漏斗模型拆解實戰的企劃階段。
第四步 原型（Prototype）：別還沒驗證就把原型做成成品
原型是設計初期的版本模型，目的是用最低成本把概念具體化來驗證，不需要做精美，只要能演示功能與樣貌即可。它的價值在於「快」與「便宜」，不在於「漂亮」。
新手最常犯的錯，是把原型當成最終成品來做。花兩個禮拜把按鈕陰影調到完美、動畫順到不行，結果拿去測試才發現整個流程方向就是錯的，那兩個禮拜直接打水漂。原型的低保真原則講得很白：紙板、手繪、粗略的點擊示意都算原型，重點是快速驗證假設，視覺完美留到最後再說。設計思考教學機構普遍建議，原型應該在幾小時到幾天內做出來，花到幾週就太久了。如果你連AWD 與 RWD 自適應設計比較都還沒釐清，就更不該在原型階段糾結視覺細節。
| 原型類型 | 常見形式 | 適合驗證 |
|---|---|---|
| 紙本原型 | 手繪畫面、剪貼 | 整體流程、資訊架構 |
| 點擊示意 | 連結跳轉的粗糙畫面 | 導覽邏輯、任務是否能完成 |
| 互動原型 | Figma 等工具的可點擊模型 | 互動細節、微互動感受 |
| 實體模型 | 紙板、泡棉做的空間或物件 | 實體服務、空間動線 |
原型保真度的選擇：對的問題用對的精度
原型不是越精細越好，而是越「對應到你想驗證的問題」越好。判斷該用哪種保真度，先問自己這一輪原型要回答什麼問題。如果要回答「整個流程會不會把人搞丟」，紙本原型就夠了，把幾張畫面攤在桌上讓使用者用手指走一遍，五分鐘就能看出哪一步卡住。如果要回答「這個微互動會不會讓人誤會」，就需要可點擊的互動原型，讓使用者真的按下去感受回饋。如果要回答「這個空間動線順不順」，紙板做的等比模型比任何螢幕畫面都更有說服力。
| 這一輪想驗證的問題 | 建議保真度 | 製作時間參考 |
|---|---|---|
| 流程順序、資訊架構 | 紙本原型 | 幾小時 |
| 導覽、任務能否完成 | 點擊示意 | 半天到一天 |
| 互動細節、回饋感受 | 互動原型 | 一到三天 |
| 視覺風格、品牌調性 | 高保真視覺稿 | 數天（且需前段已驗證） |
一個常見的浪費，是在流程還沒驗證的階段就直接做高保真視覺稿。視覺細節會綁架使用者的注意力，他會開始評論配色和字體，而忽略掉根本走不通的流程。低保真原型的「醜」反而是一種保護，它暗示使用者「這是草稿，你可以放心批評流程」。等到流程穩了，再把視覺精度拉高，這時候的視覺討論才有意義。
網頁設計最常用的原型工具是 Figma，它直觀好用、支援多人協作，可以做出可點擊的互動原型，展示結構佈局、按鈕點擊效果、導覽列彈出與動畫。如果你想系統性學這套工具，可以從Figma 中文完整入門教學開始，把基礎打穩，再視需要深入外掛、網格、動畫與響應式等進階功能。這些都是後話，不要在第一次原型就追求這個程度。
原型有雙重功能：對使用者，它用來測試假設；對開發者，它用來溝通需求、加速開發。一份清楚的互動原型，能讓工程師秒懂你要的是什麼，省下大量來回確認的時間。這對接案的設計師特別重要，因為它直接關係到你的報價能不能守住。如果你想進一步縮短設計到開發的距離，Codex AI 程式助理這類工具能協助把原型需求轉成可執行的程式任務。
第五步 測試（Test）：拿原型回去問使用者，然後回到第一步
測試是把原型交給真實使用者，觀察他們的使用行為與意見，驗證設計是否符合需求。測完之後通常不會直接定案，而是把發現的問題帶回前面幾步重新修正。
測試階段最容易踩的雷，是把它當成「證明自己對」的場合。你精心做了一個原型，內心當然希望使用者誇獎，於是當使用者卡住的時候，你會下意識幫他解釋「其實你再點一下就懂了」。但這恰恰是測試最該避免的心態。測試的目的是盡早發現錯誤，使用者卡住的那一刻，就是你這份原型最有價值的瞬間。可用性研究領域長期觀察到一個現象：使用者實際做的與他事後說的經常不一致，這也是 Nielsen Norman Group 等研究機構反覆強調的重點，所以觀察重點放在行為，意見只當參考。
測試任務設計與可用性觀察重點
測試的品質取決於你給使用者什麼任務。給「請試用看看這個功能，說說你的感覺」這種任務，你只會聽到禮貌話。給「你想買一雙給媽媽的母親節禮物，預算兩千塊，試著在這個網站上完成購買」，你才會看到真實行為。一個好的測試任務有三個特徵：有明確目標、有真實情境、不暗示操作路徑。把「請點右上角的購物車」改成「你想結帳，接下來你會怎麼做」，才能測出導覽設計到底直不直覺。
任務給對了，接下來要看的就是觀察重點。可用性測試裡最有訊息量的訊號，往往藏在行為的細微破綻裡，使用者事後說出口的評價反而參考價值有限。下表把四個關鍵觀察指標，對照成「這個訊號指向哪一層設計問題」，比起單獨看指標，更能直接連到下一步該改什麼。
| 觀察指標 | 訊號長什麼樣 | 指向的設計問題 |
|---|---|---|
| 任務成功率 | 有沒有完成、卡在哪一步 | 整體流程是否走得通 |
| 關鍵時刻的猶豫 | 停頓、游標繞圈、皺眉 | 回饋感受或文案不夠清楚 |
| 非預期路徑 | 走了一條你沒設計過的路 | 資訊架構與心智模型對不上 |
| 求助行為 | 找說明、問旁邊的人 | 這一步的能供性（affordance）不足 |
測試的數量也有講究。可用性研究領域長期流傳的經驗值是，五到八位使用者就足以暴露一個產品大約八成的可用性問題，超過這個數字之後，新發現的邊際效益會快速遞減。這也是為什麼前面建議資源有限時，做五位使用者深度測試就足以啟動迴圈。把測試拆成「小量多輪」會比「一次大量」更有效，每一輪測完立刻改原型，再測下一輪，問題會在迭代中被逐層剝掉。如果你在測試中發現問題出在轉換流程，可以回頭對照Landing Page 轉換率優化攻略，把測試得到的回饋轉成具體的優化方向。
設計思考五步驟不是直線：實戰怎麼跑這個迴圈
五步驟是一個會反覆折返的迭代，從頭走到尾的直線跑法反而會出問題。資源有限時，同理與定義這兩步絕對不能省，因為它們決定方向；發想可以精簡、原型可以低精度、測試可以小規模。
這裡要把市面上九成設計思考教學不會明講的事說清楚：把五步驟當成線性流程跑完，是多數團隊設計思考失敗的主因。它其實會不斷回頭，原型測完往往要重做定義，甚至重新同理某個之前沒注意到的使用者族群。IDEO 的 Design Kit 與史丹佛 d.school 的教材都明確指出，設計思考是迭代而非線性的過程。所以糾結「我做到第幾步了」意義不大，更該問自己「現在是在開放找答案，還是在收攏選項」。
資源分配上，建議把至少一半的心力放在同理與定義。聽起來很反直覺，因為這兩步的產出最不具體、最難向主管交代進度。但後段的發想、原型、測試，如果建立在一個錯誤的前提上，做得越扎實只是浪費越多工程資源。這個原則也適用於做SWOT 分析策略工具教學或行銷策略制定完整步驟，前段的方向判斷永遠比後段的執行技巧重要。
| 步驟 | 能否精簡 | 資源配置建議 |
|---|---|---|
| 同理 Empathize | 不能省，可縮小規模 | 至少 5 位使用者深度訪談 |
| 定義 Define | 不能省 | 寫出明確 POV 句型 |
| 發想 Ideate | 可精簡 | 一場 60 分鐘腦力激盪即可 |
| 原型 Prototype | 可低精度 | 紙筆或低保真 Figma |
| 測試 Test | 可小規模 | 5 到 8 位使用者測試 |
把這張資源配置表搬進實際情境會更有感。以一個典型的中小型產品團隊、專案週期大約六到八週的情境為例，常見的狀況是前段的同理與定義被擠壓到只剩一週左右，剩餘的時間幾乎全押在原型與開發，結果往往在第一次測試就暴露問題方向根本沒被定義清楚，只能回頭重來，整體週期反而被拉長。依這類團隊的典型表現幅度，前段研究階段若能穩定投入大約整體工時的三到四成，後段 rework 的比例通常有機會壓低到兩成以內；相對地，若前段只佔一成上下，rework 連同工程重工往往會落在三到五成之間，也就是說省下來的研究時間最後是用加倍的人力在還債。這個幅度是公開實務討論裡常見的區間，並不是某一個固定專案的量測數字。要特別提醒一個誠實的限制：上述比例是概括性的方向參考，不適合直接拿來當單一專案的預算切分依據，因為實際投入還會受到使用者族群複雜度、團隊過往研究成熟度與時程壓力顯著影響。從決策角度看，與其糾結「前段到底該佔幾成」，不如換一個更可檢驗的問法：這一輪專案結束時，有沒有任何一個原本信以為真的假設被研究發現推翻過。如果整段跑完、每場測試都只是印證既定計畫，那才是真正該警惕的訊號，代表資源配置很可能只是形式上合規，前段的收斂並沒有真正發生。
判斷「現在該發散還是收斂」的三個訊號
跑這個迴圈時，最常見的卡關是「不知道現在該繼續發散、還是開始收斂」。判斷這件事，看團隊當下的認知狀態比看流程圖更有用。當會議裡開始反覆講同一件事、沒有新的詞彙出現，代表發散已經飽和，該收斂；當白板上的點子多到沒人記得各自的重點，代表量已經夠了，接下來要靠分類與投票把它們壓縮成可討論的少數。還有一種訊號方向相反、卻更重要：當測試出現一個明顯反駁既有定義的發現，你不該收斂，反而要倒退回定義甚至同理重新來過。把發散飽和、收斂時機、定義被推翻這三種狀態分清楚，比死守步驟順序更能決定下一步。
沒有預算也能啟動這個迴圈。用紙筆畫原型，找五位目標使用者各聊 30 分鐘，就足以讓你發現前一輪沒看到的問題。光靠這個最小可行版，就能在三週內把一個模糊的想法收斂成可執行的方向。落地判斷的標準很具體：當測試連續兩輪都沒有新發現、使用者能順利完成任務，才算收斂到位。如果你想再往前推一步，把這套方法結合SEO 友善網站架構規劃與站內 SEO 與內容優化，能讓設計決策同時兼顧使用者與搜尋引擎。確認方向之後若想快速把原型推進到可運作的程度，也可以認識一下Vibe Coding 用 AI 寫程式這條新的落地路徑。
什麼情況不該用設計思考：方法不是萬能解藥
設計思考被吹捧成什麼都能解的萬靈丹，但實務上有幾種情境它反而會拖慢進度，甚至製造混亂。第一種是問題已經被充分理解、解法明確、只剩執行的情境，例如「把伺服器從舊機房搬到雲端」「依照既定規格補齊一百個頁面的內容」。這種情境需要的 是專案管理與工程紀律，硬要套設計思考的發散收斂，只會把簡單的事複雜化。
第二種不適合的情境，是時間壓力極短、容錯空間接近零的任務，例如活動上線前兩天的緊急修補。設計思考需要迭代空間，它靠「快速犯錯、快速修正」來逼近好答案，但當你連犯一次錯的時間都沒有，它的迭代優勢就完全用不上，反而該靠既有的最佳實踐與檢核表硬扛過去。第三種是純粹的合規與規範任務，答案由外部法規或標準決定，發散再多也繞不出那個框，這時候的重點是把規範讀懂、逐條對應，不是去探索使用者的潛在需求。
| 情境類型 | 該不該用設計思考 | 更合適的方法 |
|---|---|---|
| 問題模糊、需求未知 | 適合 | 設計思考、深度使用者研究 |
| 問題清楚、只剩執行 | 不適合 | 專案管理、標準作業流程 |
| 極短時間、零容錯 | 不適合 | 既有最佳實踐、檢核表 |
| 答案由外部規範決定 | 不適合 | 合規對應、逐條檢核 |
| 需要驗證商業假設 | 部分適合 | 精實創業、A/B 測試 |
還有一個更微妙的陷阱：把設計思考當成儀式跑完，卻沒有真正改變決策。有些團隊辦了同理工作坊、寫了 POV、貼了便利貼，最後還是靠主管拍腦袋定方向，那些研究產出只是用來裝飾已經決定好的結論。這種「儀式化設計思考」比完全不做更危險，因為它消耗了時間與信任，卻沒有換來任何認知更新。判斷一個團隊是不是在跑真的設計思考，最乾脆的方法是看它的決策有沒有被研究發現推翻過。如果一整年下來，每一場研究都只是印證了既定計畫，那這套方法在他們手裡只是裝飾品。
設計思考與內容、SEO 的結合：研究驅動的產出才經得起檢驗
設計思考雖然常被歸類為產品方法，但它的同理與定義紀律，恰好補上內容與 SEO 工作最缺的一塊：在動手寫之前，先把讀者真實的處境與問題搞清楚。一堆網頁內容之所以寫完沒人看，問題出在寫作者從來沒搞懂讀者到底卡在哪一句、缺哪一塊資訊，只憑自己的想像把篇幅灌滿。把同理那一步搬過來，先做搜尋意圖分析、把讀者會問的每一個子問題列出來，寫出來的內容才會真的命中需求。這條線索也可以連回內容行銷策略打造方法，把研究紀律接到內容企劃上。
這層結合在數據上是有支撐的。研究指出，Ahrefs 索引中超過九成的網頁從 Google 拿不到任何自然流量 [來源：〈Ahrefs — 96.55% of Content Gets No Traffic From Google. Here's How to Be in the Other 3.45% [New Research for 2023]〉〈https://ahrefs.com/blog/search-traffic-study/〉〈2023-12-01〉]，內容要擠進會被看見的那一小群，關鍵在於寫得對，寫得多反而不重要。把設計思考的同理與定義用在內容上，本質上就是在做「寫得對」這件事：先確認讀者真正要解的問題，再決定要寫什麼。這比無腦堆字數或堆關鍵字有效得多，也更能累積長期的搜尋信任。想進一步把研究轉成可被搜尋引擎理解的結構，可以對照站內 SEO 與內容優化與SEO 友善網站架構規劃。
新手最容易踩的陷阱：四個反覆出現的失誤
先釐清一個根本的混淆：設計思考與 UX 設計不是同一件事。設計思考是跨領域的問題解決方法論，任何需要定義問題、發想解法的場景都能用，從產品、服務到流程企劃都適用；UX 設計則是專注於數位產品體驗的設計專業，關心的是介面、互動、可用性這類細節。兩者會結合，UIUX 設計師常把設計思考當成前段的研究框架，但把兩者劃上等號，會讓你誤以為設計思考只能用在網頁設計。它的適用範圍遠比網頁設計必備關鍵元素這類主題寬廣得多。
把這個混淆分清楚之後，新手在實作裡反覆出現的失誤，幾乎都集中在同一個根源：把方法的形式跑完，卻跳過了讓方法真正發揮作用的前提。最常見的是把同理跳過、直接發想，等於在沒有依據的情況下空想，這也是設計思考失敗的第一名原因。另一個極端是只靠問卷做研究，錯過使用者說不清楚的潛在需求，問卷頂多當量化補充，不能當唯一來源。再來是把原型當最終成品做，時間全花在視覺細節，流程方向卻還沒驗證過；以及把使用者的要求當成需求，導致發想空間被解法綁死，點子全部長在同一個框裡。這幾個失誤看似分散，其實都指向同一件事：前段的同理與定義沒有真正發生。
工具選擇上，原型首選 Figma，研究可以用 AI 輔助整理資料，但不該用 AI 取代真實的使用者接觸。如果你剛起步，作品集範本與模板大全能幫你快速建立手感。等到設計收斂、要打磨到可上線的程度，色彩、排版、效能與轉換這幾塊各有專門的細節得顧，但那些都屬於後段功夫，不該在還沒確認問題方向之前就投入。
從哪裡開始：前段慢下來，才是這套方法最難的一關
設計思考最難的地方，往往不在於學會方法，而在於願意在前段慢下來。同理與定義看不到立即產出，很容易被進度壓力逼著跳過，但每一次跳過，後面都要用加倍的 rework 來還債。下一次專案，就從五位使用者的深度訪談開始，把問題方向確認清楚，再談做得精不精緻。等到設計收斂、產品要正式推向市場，下一步通常會銜接到Go-to-Market 上市策略，把「解對的問題」推進到「被對的人看見」。想把這套解題觀念內化得更深，也可以從一份好書推薦書單裡挑幾本來讀，邊讀邊對照自己的專案。
常見問題 FAQ
POV 句型寫不出來，代表什麼？
POV（Point of View）的三段是「用戶特徵＋需求＋見解」，哪一段卡住寫不出來，就表示前段的同理還缺一塊：用戶特徵寫不出代表沒聚焦，需求寫不出代表還沒分清問題與解法，見解寫不出代表動機沒挖到。
設計思考五步驟是線性的嗎？
不是。它是會反覆折返的迭代，原型測完常要退回定義甚至重新同理；把它當直線跑完，是多數團隊翻車的主因。判斷下一步該往前還是退後，看的是發散有沒有飽和、定義有沒有被測試推翻，而不是「我做到第幾步了」。
設計思考跟敏捷開發、精實創業有什麼差別？
三者可串成一條時間軸：設計思考回答「為誰解、解什麼痛」（定義問題），精實創業回答「這個方向值不值得投」（驗證方向），敏捷開發回答「確定要做的事怎麼快速交付出來」（工程交付）。硬要互相取代，會讓團隊用更快的節奏做錯的事。
什麼情況不該用設計思考？
問題已經清楚、只剩執行的任務，時間極短、容錯接近零的緊急任務，以及答案由外部法規決定的合規任務，都不適合。設計思考需要迭代與犯錯的空間，缺乏這個前提時，專案管理與既有最佳實踐會更有效。
使用者研究要做幾個人、測試要做幾輪才夠？
深度訪談與可用性測試，五位使用者就足以暴露大多數可用性問題，超過這個數字後新發現會快速遞減。測試建議拆成小量多輪，每一輪測完立刻改原型再測，直到連續兩輪沒有新發現才算收斂到位。