Empathize 是什麼？為什麼它是設計思考的第一步
設計思考 Empathize 是流程中的同理心階段，目的是先理解使用者的真實情境、行為、情緒、痛點與限制，再決定後續要解決什麼問題。它不急著做功能、畫版型或提出創意，而是把團隊從內部假設拉回使用者現場。
Empathize 的中文意思與核心任務
Empathize 通常翻成「同理」或「同理心階段」。在設計思考中，它的核心任務不是表達關心，而是透過背景研究、觀察、訪談與紀錄，理解使用者在特定情境下怎麼做決策、遇到什麼阻礙、為什麼會產生某些需求。
Alice Wang 在設計與品牌專案中常見到一個問題：團隊越熟悉自己的產品，越容易把自己的理解當成使用者的理解。因此 Empathize 的價值，是讓討論回到可被觀察、可被追問、可被整理的使用者資訊。
它和 Define、Ideate、Prototype、Test 的關係
| 階段 | 主要任務 | 和 Empathize 的關係 |
|---|---|---|
| Empathize | 理解使用者 | 蒐集行為、情緒、痛點與需求 |
| Define | 定義問題 | 把同理資料整理成問題陳述 |
| Ideate | 發想解法 | 依據已定義的問題產生方案 |
| Prototype | 製作原型 | 用低成本方式呈現可能解法 |
| Test | 測試驗證 | 確認解法是否真的改善問題 |
為什麼同理不是同情，而是理解真實情境
同情容易停在「我覺得使用者很辛苦」，同理則要回答「使用者在什麼情境下卡住，背後有哪些行為、情緒與限制」。設計思考同理階段如果只留下情緒判斷，後面很難轉成可執行的問題陳述。
Empathize 階段要解決的核心問題
Empathize 同理心階段要解決的核心問題，是把「團隊以為使用者需要什麼」轉成「使用者實際如何生活、工作、選擇與放棄」。這一階段的重點在發現未知問題，不是替既有想法找證明。
使用者現在怎麼做？
先觀察使用者目前的實際流程。例如電商結帳不只看最後是否付款，也要看使用者從商品頁、購物車、優惠碼、付款方式到發票選項中，在哪一步停下來、回頭查資料或請別人幫忙。
他們在哪裡卡住？
卡住不一定是介面難用，也可能是資訊不足、流程太長、權限不清楚、心理壓力太大。好的 Empathize 會把「不方便」拆成具體情境，例如不知道下一步、擔心填錯、找不到比較依據，或不確定自己是否符合資格。
他們說出口的需求，和真正需求有什麼差距？
使用者可能說「我想要更快」，但真正需求可能是「不要一直重複輸入資料」。使用者可能說「希望畫面好看」，背後其實是「我需要更清楚知道哪個選項比較適合我」。執行 Empathize 時，不能只收集句子，還要追問句子背後的原因。
哪些限制來自環境、制度、時間或心理壓力？
許多使用者痛點不是個人能力問題，而是情境限制。像政府線上申辦可能受限於文件格式、家庭長輩使用數位服務可能受限於設備與信任感，B2B 採購可能受限於內部簽核流程。這些限制會影響設計方向。
開始 Empathize 前的準備：背景研究、利害關係人與使用者分群
Empathize 前置作業要先縮小研究範圍，整理既有資料、利害關係人、使用者分群與研究目標。準備得越清楚，後續觀察與訪談越不會變成閒聊，也比較能避免帶著錯誤假設進場。
先做背景研究，避免帶著錯誤假設訪談
背景研究的目的不是把答案找完，而是知道哪些地方已經有資料、哪些地方還需要接觸使用者。若團隊一開始就跳進訪談，常會問出太寬、太散或太像內部會議的問題。
一般資料：現有數據、客服紀錄、評論、流程文件
可先整理網站分析資料、客服對話、表單退件原因、App 評論、門市回饋、現有服務流程文件。這些資料能幫助團隊找出常見斷點，例如同一個問題反覆被客服處理，通常代表流程或資訊表達有改善空間。
專家資料：一線人員、顧問、內部負責人、領域專家
一線人員常知道使用者沒有說出口的困難。診所櫃檯、客服、業務、校務行政、門市人員，都可能比後台報表更早看到使用者的真實行為。專家資料不能取代使用者研究，但能讓訪談問題更準。
畫出利害關係人地圖：直接使用者、間接受影響者、決策者
利害關係人地圖可以幫助團隊看見誰會使用、誰會被影響、誰會決定資源。以 B2B 軟體為例，採購主管可能是決策者，行政人員是日常使用者，IT 是導入把關者。如果只訪談其中一種人，問題會被看窄。
| 角色 | 要理解的重點 |
|---|---|
| 直接使用者 | 日常流程、操作痛點、實際限制 |
| 間接受影響者 | 服務結果如何影響工作或生活 |
| 決策者 | 選擇標準、風險考量、預算與責任 |
| 一線服務者 | 常見抱怨、例外狀況、補救方式 |
使用者分群不要太多，先聚焦 1 到 3 種
初期分群過多會讓研究失焦。建議先依照任務情境區分，例如新手與熟手、首次申辦者與回訪者、個人使用者與企業決策者。分群的目的，是讓問題更準，不是把每個人都貼上固定標籤。
設定本次 Empathize 的研究目標
研究目標要能指引資料蒐集。例如「理解第一次使用線上掛號的民眾，在哪些步驟感到不確定」就比「了解使用者需求」更可執行。好的研究目標會說清楚對象、情境與想理解的行為。
Empathize 的 6 步驟執行流程
Empathize 的執行流程可分為 6 步驟：定義使用者與情境、蒐集既有資料、接觸受訪者、進行觀察與訪談、整理行為與痛點、形成洞察與 POV。每一步都要留下可用產出。
步驟 1：定義要理解的使用者與情境
目的在於決定研究邊界。做法是寫下目標使用者、使用情境、任務與限制。例如「第一次在手機上申請政府補助的上班族」。產出物可以是一段研究範圍說明，讓團隊知道這次不處理哪些族群與情境。
步驟 2：蒐集既有資料與假設
目的在於整理已知與未知。做法是把客服紀錄、網站數據、內部流程、使用者回饋放在同一張表中，再標出團隊目前的假設。產出物是資料摘要與待驗證問題清單。
步驟 3：招募或接觸受訪者
目的在於找到與研究情境相符的人。做法是透過既有客戶、使用者名單、門市現場、社群或內部一線人員協助接觸。產出物是受訪者名單、分群標記、聯繫狀態與訪談安排。
步驟 4：進行觀察、訪談或沉浸體驗
目的在於取得真實行為與經驗。做法可以是觀察使用者完成任務、請他回想最近一次經驗，或由團隊自己走一次完整流程。產出物是錄音、逐字摘要、觀察紀錄、截點照片描述或任務流程筆記。
步驟 5：整理行為、語句、情緒與痛點
目的在於把零散資料變成可討論的洞察材料。做法是保留使用者原話，標記行為、情緒、卡點與需求線索。產出物可以是同理心地圖、痛點清單、使用者旅程片段與主題分類。
步驟 6：形成洞察與 POV，交給 Define 階段
目的在於讓下一階段能清楚定義問題。做法是把資料中的模式整理成洞察，再寫成 POV 問題陳述，例如「第一次申辦補助的上班族，在準備文件時需要更明確的資格確認，因為他擔心送出後被退件而浪費時間」。產出物是洞察句、需求句、POV 與 How Might We 問句。
Empathize 常用方法：觀察、訪談、問卷與沉浸體驗怎麼選
Empathize 方法要依問題類型選擇：想知道使用者實際怎麼做，用觀察；想理解原因與感受，用訪談；想快速確認範圍，用問卷；想體會流程阻力，用沉浸體驗。單一方法通常不夠完整。
觀察：看使用者實際怎麼做
觀察適合用來發現使用者沒有說出口的行為。像門市結帳、診所報到、線上註冊、課程報名，都能透過觀察看見停頓、求助、跳出或重複確認的瞬間。使用者說流程順，但手上動作可能已經暴露卡點。
訪談：理解原因、感受與決策脈絡
訪談適合追問「為什麼」。例如使用者放棄付款，不一定是價格問題，也可能是不信任付款頁、擔心退換貨麻煩，或看不懂運費規則。訪談時要讓使用者回到最近一次真實經驗，而不是請他抽象評價。
問卷：快速確認範圍，但不能取代同理
問卷可以幫助團隊確認某些現象是否常見，例如最多人卡在哪個步驟、最常使用哪種裝置。但問卷不容易看見背後脈絡，也容易被題目選項限制。若只靠問卷，常會得到看似整齊但難以行動的結果。
沉浸體驗：自己走一次使用者流程
沉浸體驗適合在服務流程、申辦流程或線下場域中使用。團隊可以實際從搜尋、填表、排隊、付款、等待通知到售後詢問走一遍。這種方法不能代表所有使用者，但能讓內部人員更快感受到流程阻力。
什麼情況下要混合多種方法？
| 情況 | 建議方法 | 原因 |
|---|---|---|
| 使用者說法和數據不一致 | 訪談加觀察 | 確認他們說的和做的差異 |
| 流程很長或跨部門 | 沉浸體驗加利害關係人訪談 | 看見制度與交接造成的斷點 |
| 需要先判斷問題規模 | 問卷加少量深度訪談 | 同時取得範圍與脈絡 |
| 服務有線上與線下接觸點 | 觀察加使用者旅程整理 | 避免只改善單一畫面 |
Empathize 訪談指南：從問題設計到試訪
Empathize 訪談指南要先決定訪談對象、研究問題、提問方式、問題順序、試訪、聯繫方式、訪談場域與紀錄工具。訪談品質的關鍵，是避免誘導，讓使用者說出具體經驗。
Who：要訪談誰？
先選擇與研究情境高度相關的人。若研究電商結帳，就找最近曾完成付款、放棄付款、使用優惠碼或處理退貨的人。若研究校園服務，就找真正經歷過該流程的學生、老師或行政人員。
What：這次要理解什麼？
訪談前要把想理解的問題寫清楚，例如「使用者如何判斷這個方案適不適合自己」或「使用者在哪些步驟需要求助」。What 太大，訪談會散；What 太像答案，訪談會變成驗證內部想法。
How：用開放式問題引導故事
開放式問題能讓使用者描述情境、順序與感受。例如「請你回想上次申請這項服務的過程」比「你覺得流程難不難」更好。前者會產生故事，後者容易得到簡短評分。
Sort：問題順序從暖身到深入
問題順序可從背景與最近一次經驗開始，再進入卡點、判斷依據、替代做法與未被滿足的需求。不要一開始就問最敏感或最抽象的問題，否則受訪者會用概念回答，而不是回到真實經驗。
Test：先做試訪，修掉引導性問題
試訪可以快速發現題目是否太難、太長或帶有答案。若受訪者一直回答「對」、「還好」、「應該是」，多半代表問題不夠開放。實務上，試訪後刪掉三分之一問題，常比硬塞完整題綱更有效。
Contact：聯繫受訪者並說明目的
聯繫時要說明訪談目的、時間、形式、是否錄音、資料使用方式，以及受訪者可以不回答不舒服的問題。清楚說明能降低防備，也能讓受訪者知道這不是銷售訪談或滿意度調查。
Location：選擇接近真實情境的訪談場域
訪談場域會影響回答。若要理解門市服務，最好接近門市情境；若要理解手機操作，就讓使用者用自己的手機示範。會議室很方便，但也容易讓使用者說出比較像簡報答案的內容。
Tools：錄音、筆記、同意書與紀錄表
基本工具包含錄音設備、筆記模板、訪談同意說明、觀察紀錄表與後續整理表。錄音是為了保留原話，不是讓團隊偷懶不做筆記。紀錄者應同步標記情緒、停頓、表情與動作。
好的問題：請你回想上次使用這個服務的過程
這類問題會帶出時間、場景、動機、步驟與情緒。後續可以追問「當時你怎麼判斷下一步」、「你在哪裡停了一下」、「你有沒有找別人幫忙」。好的訪談題目會讓使用者講故事，而不是配合團隊填答案。
不好的問題：你是不是覺得這個功能很難用？
這句話已經把答案放進問題裡，受訪者容易迎合訪談者。可以改成「你上次使用這個功能時，過程是怎麼進行的」或「有沒有哪一步讓你需要停下來確認」。問題越中性，越能得到真實資訊。
團隊執行 Empathize 時的角色分工
團隊執行 Empathize 時，至少要安排主持者、追問者與紀錄者，讓訪談不中斷，也讓資料品質被保留下來。跨部門專案、校園專題或服務改善會議，都不適合所有人同時發問。
主持者：控制節奏與訪談指南
主持者負責開場、說明目的、掌握時間與維持題綱順序。好的主持者不會急著證明自己的想法，而會讓受訪者有足夠時間描述經驗。若現場有主管或客戶在場，主持者也要避免權力關係影響回答。
追問者：捕捉可深入的線索
追問者負責聽出「可以再問下去」的地方，例如受訪者提到「那時候有點怕」、「我通常會先問同事」、「我不確定這樣可不可以」。這些句子通常藏著痛點與限制，比表面評價更有價值。
紀錄者：保留原話、行為與情緒線索
紀錄者要盡量保留使用者原話，並標記行為與情緒。例如「我怕按錯會不能改」比「使用者擔心流程」更有用。後者已經被團隊轉譯，容易失去細節。
訪談後 15 分鐘內完成團隊同步
訪談結束後，團隊應立刻同步重點，包含最意外的發現、可追問的線索、明顯痛點與下一場要調整的題目。時間不必長，但要在記憶還新鮮時完成。很多洞察不是出現在逐字稿裡，而是出現在剛離開現場的討論中。
Empathize 常用工具：同理心地圖怎麼用
同理心地圖是 Empathize 階段的資料整理工具，用來把觀察與訪談資料放進看見、聽見、說與做、想與感受、痛點、收穫等欄位。它不是裝飾圖表，也不是團隊憑空想像使用者。
同理心地圖適合在什麼時候使用？
同理心地圖適合用在完成幾場訪談或觀察之後，幫助團隊整理資料模式。太早使用容易變成猜測；太晚使用則可能讓資料散落在逐字稿、便利貼與會議紀錄中，難以進入 Define 階段。
六個欄位怎麼填：看見、聽見、說與做、想與感受、痛點、收穫
| 欄位 | 填寫內容 | 範例 |
|---|---|---|
| 看見 | 使用者接觸到的環境、畫面、資訊 | 付款頁有多種折扣規則 |
| 聽見 | 他人影響使用者的說法 | 朋友提醒不要亂輸入信用卡 |
| 說與做 | 使用者原話與實際行為 | 說不麻煩，但中途查了客服說明 |
| 想與感受 | 擔心、期待、猶豫與判斷 | 怕選錯配送方式造成退貨麻煩 |
| 痛點 | 阻礙任務完成的問題 | 不知道優惠是否已套用 |
| 收穫 | 使用者期待得到的結果 | 快速確認價格、配送與退貨條件 |
填寫時要用原始資料，不要用團隊猜測
同理心地圖最容易失準的地方，是團隊把自己的推測填進去。建議每一張便利貼或每一格內容，都能回到某段訪談原話、觀察紀錄或既有資料。沒有來源的判斷，可以先標成假設，留待後續驗證。
同理心地圖和 Persona 有什麼不同？
同理心地圖整理的是特定情境中的感受、行為與痛點；Persona 則是把研究結果整理成代表性使用者輪廓。Persona 可以在 Empathize 後續被建立，但不能反過來取代真實觀察與訪談。很多專案把 Persona 做得很漂亮，卻沒有研究資料支撐，這會讓後續決策變得危險。
Empathize 的產出物：怎麼銜接 Define 階段
Empathize 完成後，應輸出使用者洞察、痛點清單、需求句、POV 問題陳述與 How Might We 問句。這些產出物的作用，是讓 Define 階段能清楚接住問題，而不是重新猜一次。
使用者洞察：從資料中找到行為背後的原因
洞察不是把受訪者說過的話重複一次，而是從多筆資料中找出行為背後的原因。例如在醫療掛號情境中，多位使用者都提到「我會先打電話確認」，洞察可能是「線上資訊不足以讓使用者安心完成掛號」。
痛點清單：區分表面抱怨與結構性問題
表面抱怨可能是「網頁不好用」，結構性問題可能是「科別名稱、醫師時段與症狀判斷之間沒有清楚對應」。痛點清單要把抱怨拆成可處理的問題，並標記出現情境與影響程度。
需求句：使用者需要什麼，為了達成什麼
需求句可以寫成「使用者需要某種協助，為了完成某個目標」。例如「第一次線上掛號的民眾需要更明確的科別判斷提示，為了在不打電話的情況下安心完成預約」。需求句要避開直接寫解法，例如「需要一個聊天機器人」。
POV 問題陳述：誰在什麼情境下遇到什麼問題
POV 可以把洞察轉成清楚的設計挑戰。範例：「第一次使用線上掛號的民眾，在不確定症狀該掛哪一科時，會因為害怕掛錯科而中斷流程，因此需要在預約前得到可信任的判斷依據。」這樣的問題陳述能讓團隊進入 Define 階段。
How Might We 問句：讓團隊進入下一階段發想
How Might We 可以把 POV 轉成開放的發想入口。例如「我們可以如何幫助第一次線上掛號的民眾，在不增加壓力的情況下判斷適合的科別？」好的問句不會先指定功能，才有空間讓 Ideate 產生多種方案。
台灣常見應用情境：Empathize 可以用在哪些專案
Empathize 可用在任何需要理解人與情境的設計問題，包含產品 UX、服務設計、教育、醫療、政府服務、HR 與 B2B 專案。只要問題牽涉使用者決策、流程阻礙或體驗落差，就適合先做同理心階段。
產品與 UX：改善註冊、結帳、客服流程
產品團隊可以用 Empathize 理解使用者為何註冊到一半離開、為何購物車放棄付款、為何一直找客服。這類問題通常不是單一按鈕顏色造成，而是資訊、信任、流程與時機一起影響。
服務設計：診所、補習班、門市、政府線上申辦
服務設計很適合做觀察與沉浸體驗。診所掛號、補習班諮詢、門市退換貨、政府線上申辦，都有線上與線下接觸點。若只優化其中一段，使用者仍可能在下一段卡住。
教育：課程設計、學生學習歷程、校園服務
教育情境中的使用者不只有學生，也可能包含家長、老師、行政人員。Empathize 可以協助理解學生為什麼不交作業、家長為什麼看不懂通知、行政流程為什麼造成反覆詢問。
HR：新人到職、內部系統、員工體驗
HR 專案常見問題是內部流程設計者太熟悉制度，新人卻不知道第一天要做什麼。Empathize 可用來觀察新人到職、報到文件、內部系統登入、教育訓練與主管溝通的真實斷點。
B2B 專案：理解採購、使用者與決策者不同步的問題
B2B 專案中，購買者、使用者與維護者常不是同一群人。採購重視風險與預算，使用者重視日常效率，IT 或行政重視導入成本。Empathize 若只訪談決策者，容易忽略真正使用時的阻力。
Empathize 常見錯誤與檢查清單
Empathize 常見錯誤包含把同理當同情、只聽說法不看行為、用問卷取代訪談、提出引導性問題、訪談後不整理洞察，以及太早跳到解法。品質控管的重點，是降低假設偏誤。
把同理當成同情
錯在只留下情緒反應，沒有形成可分析資料。修正方式是把感受回到情境與行為，例如「使用者焦慮」要追到「在哪一步焦慮、因為缺少什麼資訊、造成什麼後果」。
只聽使用者說法，沒有觀察行為
錯在忽略使用者說的和做的可能不同。修正方式是請使用者示範流程，或在接近真實情境的場域觀察。當使用者說「我都看得懂」，但實際操作時停在同一頁很久，行為比評價更值得追問。
用問卷取代訪談與觀察
錯在問卷通常只能回答「多少人選了哪個選項」，很難解釋為什麼。修正方式是先用少量訪談找出問題脈絡，再用問卷確認範圍，或用問卷結果挑選值得深入訪談的族群。
問題太引導，讓受訪者迎合答案
錯在把團隊想聽的答案藏進題目。修正方式是改用中性、開放、回到經驗的問題。把「你是不是覺得這裡很麻煩」改成「你上次操作到這一步時，接下來做了什麼」。
訪談完沒有整理成洞察
錯在資料留在錄音檔、逐字稿或零散便利貼中，無法支援 Define。修正方式是訪談後立刻整理原話、行為、情緒、痛點與需求句，並把重複出現的模式標出來。
太早跳到解決方案
錯在還沒定義問題，就開始討論功能、版型或工具。修正方式是先要求團隊寫出 POV 問題陳述，再進入發想。Alice Wang 在內容與設計流程中會把這一步視為關卡，因為太早想解法，通常會讓團隊回到最熟悉但未必有效的做法。
Empathize 中文是什麼？
Empathize 通常可理解為「同理」或「同理心階段」，重點是理解使用者的真實情境、行為、情緒、痛點與需求，而不是只用自己的角度推測使用者想法。
設計思考 Empathize 一定要做訪談嗎？
不一定。訪談是常見方法之一，但實務上通常會搭配觀察、既有資料、問卷或沉浸體驗。方法選擇要看團隊想理解的是行為、原因、範圍還是流程阻力。
Empathize 和同理心地圖有什麼不同？
Empathize 是設計思考的階段；同理心地圖是這個階段中用來整理使用者資訊的工具。前者是研究任務，後者是資料整理方式。
Empathize 階段要做多久？
依專案規模而定。小型專案可能 1 到 3 天，大型服務或產品專案可能需要數週。重點不是時間長短，而是團隊是否已取得足夠洞察，能清楚進入 Define 階段。
使用者訪談要找幾個人？
初期可從 5 到 8 位開始找模式，但如果使用者分群差異很大，應依分群補足樣本。人數不是唯一標準，受訪者是否符合研究情境更重要。
沒有真實使用者可以做 Empathize 嗎？
可以先用客服紀錄、評論、內部一線人員訪談與替代使用者資料建立初步理解，但最後仍應盡量接觸真實使用者。替代資料適合起步，不適合當成最終答案。
可以用 AI 輔助 Empathize 嗎？
可以用 AI 整理訪談紀錄、歸納痛點或產生訪談問題草稿，但不能用 AI 取代真實使用者研究。AI 能協助整理資訊，無法替使用者提供真實情境與行為證據。
Empathize 的完成標準是什麼？
當團隊能清楚說明目標使用者、使用情境、主要痛點、需求與問題陳述，並能把資料交給 Define 階段使用，就可視為初步完成。
Empathize 和 Define 怎麼銜接？
Empathize 負責蒐集與理解使用者資料；Define 則把這些資料整理成明確的問題陳述或設計挑戰。常見銜接產出包含洞察、痛點清單、需求句、POV 與 How Might We 問句。
同理心階段最常見的錯誤是什麼？
最常見是帶著答案去訪談、只問封閉題、只相信問卷，以及太早開始想解法。這些錯誤會讓 Empathize 變成確認內部想法，而不是理解使用者真實需求。