設計思考 Define 是什麼？
設計思考 Define 是問題定義階段，任務是把同理階段蒐集到的訪談、觀察與行為資料，收斂成清楚、可發想的問題陳述。做完 Define，團隊通常會得到洞察、POV 與 HMW 問句，讓下一步 Ideate 不會只靠直覺想點子。
Define 最容易被低估，因為它看起來像整理資料，實際上是在做判斷。資料本身不會自動變成好問題，團隊需要從使用者說的話、做的事、遇到的限制裡，找出真正值得解決的需求。
Define 在五步驟中的位置
設計思考常見流程是 Empathize、Define、Ideate、Prototype、Test。Define 位在同理之後、發想之前，負責把「我們看到什麼」轉成「我們要解決什麼」。
- Empathize：理解使用者情境，收集證據。
- Define：整理證據，形成問題定義。
- Ideate：根據問題定義產生可能解法。
Define 的核心產出是什麼？
Define 的產出不只是會議紀錄，而是能指引後續設計方向的工作材料。
- 使用者洞察：使用者行為背後的動機、矛盾或限制。
- POV 問題陳述：說清楚使用者是誰、需要什麼、為什麼需要。
- HMW 問句：把問題轉成可進入發想的「我們可以如何」句型。
- 問題定義範圍：讓團隊知道哪些問題先處理，哪些暫時不碰。
Define 和 Empathize 差在哪？
Empathize 是收集使用者證據，Define 是根據證據做問題判斷。前者強調理解使用者，後者強調收斂焦點，避免團隊拿著一堆資料卻不知道下一步該解決哪個問題。
| 階段 | 主要任務 | 常見材料 | 判斷重點 |
|---|---|---|---|
| Empathize | 收集使用者研究資料 | 訪談逐字稿、觀察紀錄、同理心地圖、旅程圖 | 使用者實際說了什麼、做了什麼、卡在哪裡 |
| Define | 把資料收斂成問題定義 | 痛點分群、洞察、POV、HMW | 哪個問題最值得解、是否有證據、是否能發想 |
Empathize 是收集證據
同理階段的重點是盡量接近使用者真實情境，例如訪談、行為觀察、同理心地圖與顧客旅程地圖。這些資料可以讓團隊避免只用內部想像做決策。
我的判斷是，很多工作坊失敗不是因為大家不會發想，而是前面沒有把證據收好，後面只能用個人經驗補空白。
Define 是把證據收斂成問題
Define 會把零散資料整理成模式，例如哪些痛點重複出現、哪些情境最影響決策、哪些需求被使用者說得很模糊但行為上很明顯。
好的 Define 不急著寫解法，而是先把問題的對象、情境與原因說清楚。這一步做得越紮實，後面的發想越不容易偏題。
設計思考 Define 怎麼做？5 步驟完成問題定義
設計思考 Define 可以分成五步驟：整理同理資料、用親和圖分群、萃取使用者洞察、寫成 POV 問題陳述，再轉成 HMW 問句。這個順序能讓團隊從資料走到可行動的問題。
步驟 1：整理同理階段資料
先把訪談摘錄、觀察紀錄、痛點、使用者行為與情緒反應整理成可討論的單位。每一張便利貼或每一列資料最好只放一個觀察，避免後面分群時混在一起。
- 是否有使用者原話，而不只是團隊詮釋？
- 是否記錄情境，例如時間、地點、任務、限制？
- 是否區分使用者說的需求與實際行為？
- 是否保留反覆出現的痛點，而不是只挑有趣的句子？
步驟 2：用親和圖分群
親和圖適合整理大量質性資料。做法是把相似語句、相近情境、重複阻礙放在一起，再替每一群命名，例如「不知道如何開始」、「怕做錯決定」、「資訊太分散」。
命名時不要只寫表面分類，例如「網站問題」。更好的命名會帶出使用者困難，例如「比較方案時缺少可信判準」。
步驟 3：萃取使用者洞察
洞察不是把痛點換句話說，而是說出痛點背後的原因。好的洞察通常包含動機、矛盾、限制或情緒。
| 表面痛點 | 可能洞察 |
|---|---|
| 使用者說教學頁太長 | 使用者不是排斥內容多，而是在任務緊急時找不到下一步 |
| 新手不使用進階功能 | 新手擔心按錯後無法復原，所以寧願維持低效率操作 |
步驟 4：寫成 POV 問題陳述
POV 會把使用者、需求與洞察放在同一句問題陳述裡。常用格式是「某使用者需要某件事，因為某個洞察」。
例如：「剛接手專案的行銷人員需要快速判斷品牌資料是否完整，因為他們害怕在還沒搞懂背景時就做出錯誤溝通。」這句話比「改善品牌管理流程」更能引導後續設計。
步驟 5：轉成 HMW 問句
HMW 是 How Might We 的縮寫，中文可寫成「我們可以如何」。它把 POV 轉成開放但有範圍的發想題目。
以上面的 POV 為例，HMW 可以寫成：「我們可以如何幫助剛接手專案的行銷人員，在短時間內判斷品牌資料是否足夠可信？」這樣的問句保留了發想空間，也沒有直接指定要做 App、表單或簡報。
POV 問題陳述怎麼寫？
POV 問題陳述要包含使用者、需求與洞察三個元素。它的價值是把模糊痛點變成清楚的設計觀點，讓團隊知道正在為誰解決什麼問題，以及為什麼這個問題重要。
POV 公式
可套用的 POV 公式如下：
某使用者需要某項需求，因為某個從研究資料得到的洞察。
這個公式看似簡單，難點在最後一段。很多團隊會把「因為公司想提升轉換率」寫進去，但那是商業目標，不是使用者洞察。
好的 POV 範例
| 情境 | 好的 POV | 為什麼有效 |
|---|---|---|
| 新手使用後台工具 | 第一次使用後台的店家需要知道每個設定會造成什麼影響，因為他們擔心改錯後會影響正在營運的頁面。 | 使用者、需求、情緒限制都清楚。 |
| 品牌資料交接 | 剛接案的設計師需要快速理解品牌個性與使用限制，因為分散的資料會讓他們在提案初期反覆猜測方向。 | 能自然連到品牌個性與品牌指南整理。 |
| 方案比較 | 中小企業負責人需要用可信標準比較設計方案，因為他們通常無法只靠視覺偏好判斷哪個方案更符合品牌定位。 | 問題支援後續決策，而非只停在喜好。 |
不好的 POV 範例
| 不好的寫法 | 問題 | 改寫方向 |
|---|---|---|
| 我們要做一個更好用的 App。 | 預設解法，沒有使用者與洞察。 | 改成使用者在哪個情境需要什麼判斷支援。 |
| 使用者想要更好的體驗。 | 太抽象，無法發想或測試。 | 寫出是哪個任務、哪個阻礙、哪種需求。 |
| 公司需要提升會員註冊率。 | 只寫企業目標，沒有使用者中心。 | 回到使用者為何不願註冊、擔心什麼。 |
HMW 問句怎麼寫？
HMW 問句是把問題定義轉成可發想題目的方法。好的 HMW 要開放到能產生多種解法，也要具體到能讓團隊知道發想範圍，避免變成漫無邊際的腦力激盪。
HMW 的用途
HMW 的用途是讓團隊從「問題判斷」進入「解法發想」。它不直接回答答案，而是提供一個有邊界的問題框架。
實務上，我會把 HMW 當成發想前的品質門檻。若問句寫得太空，便利貼會很多，但真正能推進原型與測試的方向很少。
HMW 句型公式
常用句型是：「我們可以如何幫助某使用者，在某情境下，達成某項需求或降低某個阻礙？」
可以依情境微調：
- 我們可以如何幫助新手使用者在第一次操作時知道下一步？
- 我們可以如何讓決策者在比較方案時看見品牌定位差異？
- 我們可以如何降低使用者在送出表單前的不確定感？
HMW 範例：從痛點到問句
| 原始痛點 | 洞察 | POV | HMW |
|---|---|---|---|
| 使用者看不懂設定頁。 | 他們真正害怕的是設定錯誤後無法復原。 | 第一次設定後台的店家需要知道每個選項的後果，因為他們不想影響營運中的頁面。 | 我們可以如何幫助第一次設定後台的店家，在操作前理解每個選項的影響？ |
| 客戶一直修改設計方向。 | 客戶不是故意反覆，而是缺少判斷品牌一致性的標準。 | 品牌專案負責人需要清楚的判斷依據，因為只用主觀喜好會讓討論失焦。 | 我們可以如何幫助品牌專案負責人用一致標準判斷設計方向？ |
| 使用者不完成註冊。 | 他們在不知道註冊後會收到什麼內容時，會先保留個人資料。 | 第一次接觸服務的使用者需要知道註冊後的實際價值，因為他們不想把資料交給不熟悉的品牌。 | 我們可以如何讓第一次接觸服務的使用者，在註冊前理解資料交換的價值？ |
HMW 句子太大或太小怎麼修？
| 問題類型 | 不佳 HMW | 修正後 HMW |
|---|---|---|
| 太大 | 我們可以如何提升使用者體驗？ | 我們可以如何幫助第一次使用後台的店家，在五分鐘內找到最重要的設定入口？ |
| 太小 | 我們可以如何把按鈕改成綠色？ | 我們可以如何讓使用者更容易辨識下一個安全步驟？ |
| 預設解法 | 我們可以如何做一個 App 提醒使用者？ | 我們可以如何在使用者忘記關鍵任務時提供適時提醒？ |
Define 階段常用工具有哪些？
Define 階段常用工具包括 Persona、同理心地圖、顧客旅程地圖、親和圖、5 Whys、POV 與 HMW。工具的選擇取決於目前卡在哪裡：不清楚使用者就用 Persona，不清楚模式就用親和圖，不清楚原因就用 5 Whys。
| 工具 | 適合時機 | 主要用途 | 常見誤用 |
|---|---|---|---|
| Persona | 使用者輪廓不清楚時 | 界定使用者目標、限制與情境 | 只寫年齡、性別、職業 |
| 同理心地圖 | 需要整理想法、感受、行為時 | 把研究資料變成可討論線索 | 用團隊猜測取代研究資料 |
| 顧客旅程地圖 | 需要看完整任務流程時 | 找出接觸點與卡關段落 | 畫得很漂亮但沒有決策用途 |
| 親和圖 | 資料很多且混亂時 | 分群、找模式、收斂痛點 | 先有結論再硬分群 |
| 5 Whys | 痛點停在表面時 | 追問根因 | 把每個答案都問到牽強 |
| POV、HMW | 準備進入發想前 | 形成問題陳述與發想題目 | 把解法包裝成問題 |
Persona
Persona 在 Define 階段的用途是幫助團隊明確知道正在為誰定義問題。有效的 Persona 會包含角色、目標、限制、使用情境與決策壓力。
如果 Persona 只剩「25 到 35 歲女性上班族」，它對問題定義幫助有限。Define 需要的是行為與情境，不是人口統計堆砌。
同理心地圖與顧客旅程地圖
同理心地圖適合整理使用者想什麼、說什麼、做什麼、感受到什麼。顧客旅程地圖則適合整理任務流程與接觸點，例如使用者從搜尋、比較、詢問到決策的每一步。
兩者都不是最終答案，而是幫助團隊找出可被 Define 的材料。
5 Whys
5 Whys 透過連續追問「為什麼」找出根因。例如使用者沒有完成品牌資料表，不一定是表單太長，可能是他們不知道哪些資料會影響後續設計方向。
追問到能改寫問題定義就可以停，不需要為了湊滿五次而把原因問歪。
親和圖
親和圖適合在工作坊中快速整理大量便利貼。操作時先不討論解法，只看哪些觀察彼此相近，再替每一群命名。
好的群組名稱會讓洞察浮出來，例如「怕承擔錯誤決策」比「決策問題」更有發想價值。
好的問題定義要符合哪些標準？
好的問題定義要以使用者為中心、足夠具體、有研究證據、能引導發想，且不能預設單一解法。它應該讓團隊看得出問題範圍，也保留不同解法的可能性。
以使用者為中心，而不是以公司為中心
使用者中心的問題定義會描述使用者在特定情境下的需求與限制。公司中心的寫法則常以營收、註冊率、留存率開頭。
| 公司中心寫法 | 使用者中心改寫 |
|---|---|
| 我們要提升品牌指南下載量。 | 第一次接觸品牌專案的客戶需要知道品牌指南能幫他減少哪些溝通成本，因為他不確定下載後是否值得花時間閱讀。 |
| 我們要提高廣告設計轉換。 | 正在比較設計方案的行銷人員需要看見訊息層級與視覺焦點，因為他們必須判斷哪個版本更能支持投放目標。 |
夠具體，但不要窄到只剩一個解法
問題定義要能讓團隊開始想解法，但不能窄到只剩一種答案。若句子裡已經出現「做 App」、「新增通知」、「改成影片」，通常代表已經太早跳到解法。
比較好的尺度是描述任務與阻礙，例如「讓新手在第一次設定時理解後果」，而不是指定「新增教學彈窗」。
有研究證據支撐
問題定義最好能回到訪談摘錄、觀察紀錄或行為資料。若團隊找不到任何證據，只能說「我們覺得使用者應該會」，這個 Define 風險就高。
- 是否有至少一段使用者原話支持？
- 是否有觀察到的行為，而不是只有意見？
- 是否能說出這個問題出現在哪個情境？
- 是否排除純粹來自內部偏好的判斷？
設計思考 Define 常見錯誤
Define 常見錯誤包括把解法寫成問題、問題太抽象、問題範圍太大、缺少使用者證據，以及把商業目標包裝成使用者需求。這些錯誤會讓後續發想看似熱鬧，實際上偏離真正問題。
把解法寫成問題
「做一個 App」不是問題定義，因為它已經決定了解法形式。更好的寫法要回到使用者遇到什麼阻礙，例如「使用者在外出時需要即時確認任務狀態，因為他無法隨時回到電腦前查看」。
問題太大，無法發想
「提升使用者體驗」太大，團隊很難知道要從哪裡開始。可以改成「幫助第一次使用者在完成註冊後找到最關鍵的下一步」，這樣才有機會連到原型與測試。
沒有回到使用者證據
沒有證據的 Define 容易變成主管偏好或團隊猜測。檢查方式很直接：請團隊說出這句問題定義來自哪段訪談、哪個觀察、哪個行為資料。
| 錯誤句子 | 風險 | 可改寫方向 |
|---|---|---|
| 使用者需要更多功能。 | 沒有證據，也不知道是哪種功能。 | 使用者在比較方案時需要看懂功能差異。 |
| 我們要讓品牌看起來更高級。 | 偏向內部審美，缺少使用者任務。 | 目標客群需要在第一眼理解品牌定位與信任感。 |
| 客戶都不懂設計。 | 把問題推給使用者，無法產出設計方向。 | 客戶需要更清楚的判斷標準來比較設計提案。 |
Define 和產品規格、商業決策有什麼關係？
Define 不是產品規格，但它會影響需求整理、功能優先順序與規格方向。清楚的問題定義能讓 PM、設計師與商業決策者先對「為什麼做」形成共識，再討論「要做什麼」。
Define 不是產品規格，但會影響規格方向
產品規格通常會描述功能、條件、流程與限制；Define 則描述使用者問題與設計方向。兩者的關係是問題定義先於規格細節。
| 層級 | 回答的問題 | 範例 |
|---|---|---|
| Define | 使用者真正需要解決什麼？ | 新手需要在第一次設定時理解每個選項的影響。 |
| 需求條件 | 解法需要滿足哪些條件？ | 需要能預覽影響、能回復設定、能看見風險提示。 |
| 產品規格 | 實際要如何實作？ | 設定頁加入預覽區、復原按鈕與分級提示。 |
好的 Define 可以降低做錯功能的機率
功能做錯，常不是執行能力不足，而是一開始解錯問題。Define 能讓團隊先確認使用者需求、情境與洞察，再決定哪些功能值得排進規格。
對商業決策者來說，Define 的價值在於降低無效投入。它讓「我想做這個功能」變成「這個功能是否真的回應已驗證的使用者問題」。
為什麼 Define 做得好會影響後續成效？
Define 會影響 Ideate 的方向、Prototype 的假設與 Test 的判斷標準。問題定義越清楚，後續每一步越容易知道自己在驗證什麼，也更容易在測試後回頭修正。
Define 決定發想方向
如果 Define 寫錯，後面的發想就會朝錯方向努力。假設問題被定義成「使用者不喜歡閱讀」，團隊可能急著改成影片；但若真正洞察是「使用者在時間壓力下找不到重點」，更有效的方向可能是重新整理資訊層級。
這也是為什麼定義品牌問題或規劃產品方向時，不能只看內部想做什麼，還要回到使用者在情境裡的判斷方式。
Define 可以在測試後回頭修正
設計思考不是一次走完就結束的線性流程。原型與測試可能會揭露新的使用者限制，團隊需要回頭修正洞察、POV 或 HMW。
成熟的團隊不會把第一次 Define 當成定案，而會把它當成可被驗證的問題假設。這種態度比套公式更重要。
設計思考 Define 是什麼？
設計思考 Define 是把同理階段資料收斂成問題定義的階段。它會把訪談、觀察、痛點與使用者需求整理成洞察、POV 問題陳述與 HMW 問句，作為後續發想的依據。
Define 和 Empathize 差在哪？
Empathize 負責理解使用者並收集證據，Define 負責根據證據判斷要解決哪個問題。前者偏向探索，後者偏向收斂。
Define 階段會產出什麼？
Define 階段常見產出包括使用者洞察、POV 問題陳述、HMW 問句、痛點分群與問題定義範圍。這些產出會影響後續 Ideate、原型與測試方向。
POV 問題陳述怎麼寫？
POV 可用「某使用者需要某項需求，因為某個洞察」來寫。重點是同時說清楚使用者、需求與原因，不要只寫公司目標或直接指定解法。
HMW 問句是什麼意思？
HMW 是 How Might We 的縮寫，中文常寫成「我們可以如何」。它把問題定義轉成可發想的問句，幫助團隊產生多種解法方向。
Define 和 HMW 是一樣的嗎？
不一樣。Define 是設計思考中的問題定義階段，HMW 是 Define 後常用的問句格式。Define 會產生洞察與 POV，HMW 則把這些內容轉成發想題目。
問題定義可以在後面階段修改嗎？
可以。原型與測試可能揭露新的使用者限制或錯誤假設，團隊應該回頭修正問題定義。Define 比較像可驗證的問題假設，不是一次寫完就永遠固定。
Define 階段最常見的錯誤有哪些？
常見錯誤包括把解法寫成問題、問題太抽象、範圍太大、沒有使用者證據，以及把商業目標當成使用者需求。這些錯誤會讓後續發想偏離真正問題。
Persona 在 Define 階段有什麼用？
Persona 可以幫助團隊界定正在為誰解決問題。有效的 Persona 會描述使用者目標、情境、限制與決策壓力，而不只是年齡或職業資料。
Define 和產品規格有什麼關係？
Define 不是產品規格，但會影響規格方向。它先說清楚使用者問題，再讓團隊推導需求條件、功能優先順序與產品規格。
問題定義要寫得越大越好嗎？
不是。問題太大會難以發想和測試，太小又可能只剩單一解法。好的問題定義要有具體情境與清楚需求，同時保留多種解法可能。
沒有訪談資料可以做 Define 嗎？
可以先做暫時性的問題假設，但風險較高。最好補上使用者訪談、行為觀察、客服紀錄、搜尋紀錄或既有研究資料，避免 Define 只建立在團隊猜測上。