設計思考五步驟完全指南：用同理心解決問題

你是不是也遇過這種會議：一整個下午，會議室牆上貼滿了五顏六色的便利貼，大家輪流說「我覺得使用者會⋯⋯」，看起來很有參與感、很有創新味，但會議結束那天，牆上那些便利貼連同你對使用者的想像，一起被收進抽屜裡再也沒有拿出來。先把這個畫面放著，等你把整篇讀完，你就會知道問題出在哪。

設計思考（Design Thinking）的價值不在背誦五個步驟，而在尚未確定需求時，先用研究與測試檢查團隊假設。流程可拆成同理、定義、發想、原型與測試；每一步都應回到具體問題、證據與可驗證假設，並依專案條件決定是否適用。

先說結論：設計思考不是流程圖，是一種「拒絕自嗨」的紀律

很多人把設計思考理解成一張由左到右的流程圖，做完同理、做完定義、做完發想，一路走到測試，然後就「創新完成」了。這個理解是錯的，而且錯得很有殺傷力，因為它讓人誤以為只要走完流程，就會得到好結果。

換句話說，設計思考真正在做的事情只有一件：用一套紀律，不斷把你從「我以為」拉回到「使用者真的是」。它比較像一面鏡子，會把你腦裡的假設照出來。按一個按鈕就吐答案的機器，做不了這件事。你每走一步，它就提醒你一次：你現在手上這個結論，是來自使用者的真實行為，還是來自你自己坐在辦公室的推測？

用一個對比來講會更清楚。

把設計思考當「流程圖」	把設計思考當「紀律」
目標是走完五步	目標是每一次假設都被驗證過
便利貼貼得越多越有成就感	能被推翻的假設越多越有價值
開一場工作坊就算導入	把它變成開發節奏裡的固定動作
做完測試就結案	測試結果直接決定要不要繞回第一步
產出是一份簡報	產出是一個「被使用者行為修正過」的決策

右邊那一欄才是設計思考本來的樣子。如果團隊把它操作成左邊那欄，那就只是在演一場看起來很創新的戲，戲演完，產品一樣賣不動。後面會專門談這種「創新劇場」是怎麼發生的。

為什麼九成產品（和九成內容）沒人要：你以為你知道，但你不知道

這裡先看一個內容面的數字。Ahrefs 針對上百萬頁網頁的研究（2023）發現，超過九成的內容沒有從 Google 取得自然搜尋流量。這份資料描述的是搜尋流量，不能直接推算產品失敗率；它能提醒我們，投入產出之前先驗證需求與可見性條件。

這兩件事其實是同一個病。內容拿不到流量，多半不是因為寫得不夠長或不夠漂亮，而是因為它回答的問題，根本沒有人在問；產品賣不動，多半跟功能不夠多沒有關係，真正的問題是它解決的問題，根本沒有人急著要被解決。兩者的源頭都是同一個動作出錯了：作者或開發者在起跑那一刻，用的是自己的想像，把使用者的真實處境完全拋在一邊。

這就是設計思考要對付的東西。它的五個步驟，本質上是在反覆校正「你想像的使用者」與「真實的使用者」之間的落差。你越願意在前期被校正、被推翻，後期浪費在錯誤方向上的力氣就越少。換句話說，設計思考是一種把「自嗨成本」提前付掉的機制。

換個比喻來講。假設你要開一間咖啡館，你在設計階段就認定「客人最在意的是咖啡豆的產地」，於是把預算全砸在精品豆、產地故事牆與咖啡師履歷。開幕後才從營運資料發現，這一帶的客人多半是趕著上班的通勤族，更在意出杯速度與座位。這個落差就是設計思考要幫你降低的風險。正式投入前，至少安排數個時段觀察與訪談，避免用單一早上的樣本下結論。

有一個觀念要先種在你心裡，後面會反覆用到：使用者很少會直接告訴你他要什麼，他只會告訴你他在煩惱什麼。你能不能把「煩惱」翻譯成「需求」，就是這整套方法的核心功課。如果你對「我們到底能不能真的理解另一個人的內心」這件事的哲學底層有興趣，哲學裡的「他心問題」談的正是同一個根本難題。

把五步驟重新拆成「五個轉換點」：一張表看懂教科書版與實戰版的差異

史丹佛 d.school 提出的五個步驟：同理（Empathize）、定義（Define）、發想（Ideate）、原型（Prototype）、測試（Test），是大家最熟悉的版本。與其把這五步看成固定階段，不如把它們看成五個「轉換點」，也就是資訊從一種形式變成另一種形式的關卡。多數專案出事，問題很少出在某一步內部，通常出在兩個步驟之間的轉換沒有轉乾淨。

步驟	教科書版的任務	實戰版的轉換點：什麼要被轉換	最常見的卡點
同理 Empathize	觀察與訪談使用者	把「使用者的處境」轉成「你腦中的具體畫面」	只聽他說的話，沒看他實際怎麼做
定義 Define	收斂出一個問題陳述	把「一堆雜訊」轉成「一句可被解決的問題」	把現象直接當問題，沒挖到動機層
發想 Ideate	大量產出點子	把「一句問題」轉成「一籃子可能的解法」	太早把點子拿來比好不好
原型 Prototype	做出可互動的版本	把「抽象的解法」轉成「可以被手指戳的東西」	原型做太精緻，回饋全被外觀綁架
測試 Test	拿原型給使用者用	把「你以為會成立」轉成「被行為證實或推翻」	測的是好感度，不是使用行為

把表格右邊那一欄記下來。後面五個小節，會帶你走過這五個轉換點各自的實戰要點，但請你隨時回頭對照這張表，因為真正決定成敗的，是那些「卡點」有沒有被處理掉，步驟有沒有被走完反而是次要的。

同理（Empathize）：不是發問卷，是把自己塞進使用者的處境

同理這一步最常被做歪，歪法還滿一致的：開一份 Google 表單，發出去，回收三百份，算一算平均數，然後宣布「我們已經了解使用者」。老實說，問卷不是不能用，它是使用者研究裡成本最低的工具，但它問得出來的東西有上限。人類在填問卷的時候，會本能地給出「自己覺得體面」的答案，掩蓋掉自己真實做的選擇。問卷告訴你他「說」了什麼，卻很少告訴你他「做」了什麼。

同理真正要建立的，是一種你對使用者的「情境記憶」。你要能夠在腦海裡調出一個具體的人、一個具體的時刻、一個具體的動作，絕對不能只停留在平均數。這種記憶只有幾種來源：你親眼看他操作、你坐在他旁邊聽他抱怨、你把自己丟進他每天都在走的那條流程裡親自走一遍。

幾個實務上特別有效的動作，給你參考。

• 現場觀察優先於訪談。先看他怎麼做，再問他為什麼。你會發現他嘴裡講的理由，跟他的手指實際按的按鈕，常常是兩回事。
• 問行為，不問意見。「你上次遇到這個狀況是什麼時候，你接下來做了什麼」遠比「你覺得這個功能好不好」有價值。意見可以被編造，行為的細節很難。
• 納入極端使用者，也保留核心客群樣本。新手與重度使用者常能暴露邊界問題，但仍要涵蓋實際目標客群，避免把少數極端需求誤當成普遍需求。
• 自己當一天的受訪者。把你自己丟進你正在設計的那條流程，親自走一次，你會立刻知道哪一步讓人想摔滑鼠。

還有一個同理階段的陷阱，是受訪者本身的專業背景越強，你越要小心。當你訪談的對象是業內同行、或是對這個領域很熟的人，他給你的答案會異常地「漂亮」，因為他已經幫你想好了一整套邏輯。但這套邏輯是他這個角色才有的視角，不代表你的目標使用者。實務上的做法是，訪談完一定回頭問自己一句：他剛剛講的這些，是一個第一次碰到這個問題的人也會這樣想嗎？如果答案是否定的，那他的洞察再精彩，也只能當參考，不能當你定義問題的地基。同理要採集的，從來不是最聰明的那個觀點，而是最普遍、最笨拙、最真實的那個卡關瞬間。

把這些素材整理成具體的人物輪廓，後面定義步驟才會有東西可以收斂。如果你還沒有把使用者結構化記錄下來的習慣，我們還寫過一篇Persona 人物誌建立指南，可以把你在同理階段蒐集到的零散觀察，固定成一個之後整個團隊都能對齊的參考對象。同理階段的產出，理想上也應該對應到一條客戶與產品互動的完整動線，這部分可以搭配顧客旅程地圖一起看，你會更清楚使用者是在哪個接觸點被你漏接的。

定義（Define）：把雜訊收斂成一句「他其實在煩惱什麼」

同理結束的時候，你手上會有一團亂七八糟的筆記、錄音、照片、觀察，資訊量爆表。定義這一步要做的，是把它們收斂成一句話，一句你的團隊能用來判斷「這個解法有沒有答到題」的話。

這句話不好寫。最常見的失誤，是把一個「現象」直接當成「問題」。

舉個例子。你在觀察裡發現「使用者打開我們的報名頁，停留了四十秒，然後離開」。這是一個現象，不是問題。如果你把問題定義成「使用者停留時間太長，要縮短頁面」，你八成會去改版面、刪欄位。但真正的問題可能是「他不知道這個報名到底要綁信用卡還是不用」，所以他在猶豫。兩個定義，會帶你走向完全不同的解法，一個去動設計，一個去動資訊揭露。

要怎麼把現象挖到真正的問題？實務上的判斷標準是：一個好的問題陳述，要描述「使用者在什麼情境下、想要完成什麼、但被什麼卡住」，而且這個「卡住」要落在動機層，不能停在行為層。行為層是「他沒點按鈕」，動機層是「他不知道點了會發生什麼事」。

帶團隊收斂的時候，會用一個很老派但很好用的填空格式，來逼大家把問題寫具體：【某類使用者】在【某個情境下】想要完成【某件事】，但是他被【某個阻礙】卡住了，他真正在意的是【某個更深層的動機】。這個格式之所以有效，是因為它強迫你把五個欄位都填滿，而你通常會卡在最後一欄，那個「更深層的動機」。這個填空句型在設計思考教材裡有個正式名字，叫 POV（Point of View）問題陳述，只是欄位拆得更細：誰、需要什麼、以及支撐這句話的洞見。你卡住的那一刻，就是你發現自己其實還不夠懂使用者的那一刻。這時候不要硬填，回去再做一輪訪談。寧可慢一輪，也不要交出一句連自己都不太相信的問題陳述，因為後面整個發想都會蓋在這句話上面，地基歪了，上面蓋什麼都會跟著歪。

這個把「表面行為」翻譯成「底層動機」的動作，跟行銷裡一個很有用的觀念是完全相通的，也就是不要問「使用者買了什麼」，要問「使用者僱用這個產品來完成什麼任務」。如果你的問題陳述寫不出來，通常是你還沒把他真正想完成的「任務」講清楚，這時候想深入可以讀JTBD 用途理論，它就是一把專門用來挖這一層的鏟子。

定義完成之後，你應該得到一句團隊所有人都點頭的問題陳述。這句話是接下來發想的唯一評分標準，所以它必須夠具體、夠聚焦、夠有方向感，絕對不能是一句「我們要提升使用者體驗」這種對誰都沒有約束力的話。

發想（Ideate）：量產點子之前，先架好「不評判」的護欄

到了發想這一步，人性的另一個弱點會跑出來：我們太愛在點子剛冒出來的那一刻，就判它生死。這個習慣在日常生活裡是高效的，但在發想階段是有毒的，因為最有潛力的點子，往往長得一副不太正經的樣子，第一秒就被你內心的審查官槍斃掉。

所以發想階段真正要做的事，不是「努力想出點子」，而是「努力保護點子不被提早殺掉」。你要做的是架護欄，把「產出」跟「評估」在時間上徹底分開。

幾個實用的護欄設計。

1. 先設量，再設質。給團隊一個明確的數字目標，例如「三十分鐘內產出四十個點子」。當大腦被逼著衝量，它就沒有餘裕去審查每一個念頭合不合理。
2. 禁用三個字。在這個階段，「但是」「不行吧」「我們之前試過」這三個字全面禁用。任何一個點子被講出來的時候，下一個人只能接「對，而且⋯⋯」把它推得更遠，不能用「對，可是⋯⋯」把它收掉。
3. 故意鼓勵荒謬。實務上常要求團隊在最後五分鐘，專門產出「預算無上限、技術無限制」的點子。這些點子九成不會被採用，但它們會把整個團隊的想像力邊界推開，推開之後，中間那些可行的點子才會跟著冒出來。
4. 評估分開做。量產結束之後，另開一個時段，把所有點子攤開來，用兩個維度排序：對使用者的價值有多高、我們執行的可行性有多高。把高價值高可行的挑出來進原型。

這四個護欄看起來像在調整氣氛，其實是在處理權力差異與從眾效應。少了其中任何一個，發想都可能退化成「資深的人講話，資淺的人點頭」。

原型（Prototype）：用最醜的版本，換最誠實的回饋

原型這一步的核心矛盾，反直覺到值得停下來想一下：原型做得越精緻，你得到的回饋越不可信。

原因是這樣的。當你拿一個畫面漂亮、互動流暢、配色到位的原型給使用者看，他大腦裡會自動切換成「評審模式」，開始挑剔配色、字體、按鈕圓角，因為這些是他覺得自己有能力評論的東西。至於「這個流程到底有沒有解決我的問題」，他反而講不出個所以然，因為那不是他被邀請評論的題目。結果就是，你花越多力氣把原型做漂亮，回收到的意見就越集中在表面，越碰不到結構。

所以原型設計的第一條鐵律是：用最低的精緻度，去測你最不確定的那個假設。你越不確定的東西，越要用粗糙的方式快速驗證，因為粗糙可以告訴受測者「這還沒定案，你可以放心說實話」。

這裡有一個常被混淆的觀念要順手釐清。原型有很多種 fidelity（擬真度），從紙筆畫的草圖、灰階線框稿，到高擬真的可點擊版本，每一種回答的問題不同。紙原型適合驗流程順序、線框稿適合驗資訊架構、高擬真適合驗視覺與互動細節。如果你把這三件事的順序搞錯，例如一開始就做高擬真去問「流程對不對」，你會得到一堆對顏色的意見，卻測不到流程。對於不同層級原型的差異與設計要點，我們在UI Prototype 原型設計全解析裡有更展開的討論。

原型類型	適合回答的問題	成本	常被誤用的場合
紙原型	流程順序對不對、選項夠不夠	極低	被嫌太醜不敢拿出來用
線框稿 Wireframe	資訊架構、頁面優先順序	低	拿去問「好不好看」
可點擊互動原型	關鍵任務能不能走完	中	做得太完整，改一個地方要重做
高擬真視覺稿	配色、字體、細節感受	高	太早做，把後面的測試空間鎖死

記住一個原則：原型的任務是「替你的假設找麻煩」，不是「替你的設計護航」。你做原型之前要先想清楚，這一輪到底要驗哪一個假設，然後用剛剛好能驗證它的最低精緻度去做就好。

測試（Test）：你測的是「他會不會用」，不是「他喜不喜歡」

測試這一步，最危險的失誤是把「好感度」當成「可用性」。這兩件事完全不同，但被搞混的頻率非常高。

好感度是情緒反應，它會被外觀、品牌與受測者的禮貌影響。你問使用者「你覺得這個設計怎麼樣」，很可能只得到「還不錯」「滿清楚的」這類社交上安全的答案。把這些話收進報告裡寫「使用者反應正面」，仍不足以證明購買或使用意願，因為「還不錯」不是行為訊號。

真正要測的，是行為。他會不會在不被你提示的狀況下，自己走到你設計的那個按鈕？他會不會在那個你以為很直覺的步驟停下來發呆？他會不會在離開之後，還記得自己剛剛做完了什麼？這些觀察遠比他嘴上的評分有訊號量。

幾個讓測試「測到行為而非意見」的做法。

• 給任務，不給路徑。告訴受測者「請幫我完成某件事」，不要告訴他「請點右上角那個按鈕」。他要能自己找到路徑，這個設計才算及格。
• 要他出聲思考。請他把腦袋裡的念頭邊操作邊講出來。你會聽到他在哪一步猶豫、在哪一步猜測、在哪一步差點放棄，這些都是黃金訊號。
• 觀察他的猶豫，不是他的完成。完成任務不一定是好設計的證據，因為人很會硬拗出一條路。真正的訊號藏在他停下來、皺眉、回頭看的那幾秒。
• 分開測，別一次測全部。一次塞五個新設計給受測者，他會混淆，回饋會糊掉。每一輪只測一到兩個關鍵假設。

測試的結果，通常不會是一個乾淨的「過關」或「沒過關」。你會得到一張修正清單，然後要決定：這些修正要不要回頭改原型、改問題陳述，甚至改你對使用者的根本假設。這就是設計思考之所以是循環、不能當直線走的原因。測試往往會把你踢回同理那一步重新開始，而這不是失敗，這是這套方法最值錢的時刻。

有一個更實際的問題要接著問：當你收回來的回饋彼此矛盾，有人說太複雜、有人說太陽春，你該聽誰的？實務上的判斷原則是這樣，先不要去秤有幾個人支持哪一邊，因為設計不是投票。你要回去把這兩群人對應到你的人物輪廓，看清楚他們是不是同一類使用者。很多時候，矛盾的回饋其實在告訴你一件事，你這個產品想同時服務兩種需求完全不同的人，而他們本來就不該被塞進同一條流程。這種洞察比任何一句好評都值錢，因為它直接幫你砍掉了一個錯誤的市場假設，讓你及早決定這兩條路要不要拆成兩個產品。

如果你的測試場景是落在轉換導向的頁面，例如活動報名或商品購買，那麼「測行為」這個原則還可以再往下接到一整個轉換率工程的體系，我們在CTA 行動呼籲按鈕設計指南裡對於「按鈕要測什麼」有更展開的拆解，可以接著讀。

設計思考最常被誤用的三種場合，以及實務上怎麼拆

設計思考是一套好方法，但它有三個特別容易長歪的使用場合，實務上太常見。與其講它多好用，這裡先把這三個地雷點出來，讓你不要踩。

第一種誤用：把工作坊當成導入

很多公司以為「辦一場兩天的設計思考工作坊」就等於「導入設計思考」。工作坊結束，牆上的便利貼撕掉，一切打回原形，開發流程跟之前一模一樣。這是最典型的「創新劇場」，過程很有感，產出等於零。真正的導入，是把設計思考的幾個關鍵動作（例如開發前先做使用者訪談、上線前先做低擬真原型測試）變成開發節奏裡不可跳過的固定步驟，絕對不能只停留在一年一次的年度盛事。

第二種誤用：用在已經有明確答案的問題上

設計思考適合處理「我們不確定使用者要什麼」這種問題，不適合處理「我們已經知道要做什麼，只是需要把它做好」這種問題。如果你今天面對的是一個規格已經明確、使用者行為已經穩定、只剩執行細節要打磨的任務，硬套設計思考只會拖慢進度、消耗團隊耐心。同樣不適合的，還有時間極短、容錯接近零的緊急任務，以及答案由外部法規決定的合規工作，因為它們都給不起設計思考需要的迭代與犯錯空間。把它留給真正的「未知」。

第三種誤用：把同理當成一次性的前置作業

有些人把同理放在專案最前面做一次，做完就以為「使用者已經懂了，不用再碰」。但使用者會變，市場會變，他昨天要的東西跟三個月後要的可能已經不一樣。同理比較像一條要持續維護的訊號線，根本沒有所謂做一次就終身有效的通行證。健康的節奏是，每當測試結果跟你的預期出現明顯落差，就代表你對使用者的理解過期了，該重新回去同理。

把這三個誤用記下來，你會比大多數把設計思考掛在嘴上的人更清醒。一個方法的價值，往往不在你什麼時候用它，而在你什麼時候選擇不用它。

把設計思考接上行銷與 SEO：同理心就是搜尋意圖的源頭

講到這裡，要把視角拉高一層，談一件多數設計思考文章不會講、但對你最有用的事：設計思考跟行銷、跟 SEO，其實是同一件事的不同切面。

你可能會問，這不是兩個不同領域嗎？表面上是，但骨子裡它們在問同一個問題：「對方到底要什麼」。設計思考問的是使用者要什麼產品（這正是整個 UI/UX 設計 工作的源頭），行銷問的是消費者要什麼價值，SEO 問的是搜尋者要什麼答案。這三個問題的源頭都是同一個動作：放下自己的假設，去搞清楚對方腦袋裡在想什麼。

所以當你做 SEO 的時候，你其實也在做設計思考的第一步，只是你拿來同理的素材換了，訪談錄音換成了搜尋字詞。每一筆搜尋，都是一個活生生的人，在某個具體情境下，把他當下的煩惱打進搜尋框。你的工作不是把這些字詞塞進文章裡衝排名，你的工作是讀懂他打這串字的時候，心裡到底卡在哪、想被解決什麼。這就是搜尋意圖（Search Intent），而它的源頭，就是設計思考講的同理心。

前面提到 Ahrefs 那個數字，超過九成的內容拿不到 Google 流量。再補一個方向一致的觀察：HubSpot 在其行銷統計彙整裡，引用 2026 年 State of Marketing 報告指出，理解消費者需求與提供個人化體驗，是近年高績效行銷團隊最持續加碼的能力。把這兩份資料擺在一起，訊號很清楚：不管是內容還是產品，能贏的那批人，都是「真的搞懂對方要什麼」的那批。而搞懂的方法，設計思考已經幫你整理好了。

這也是為什麼 AI 大量產出的內容，在這幾年越來越難拿到排名。AI 能模擬同理的語氣，但它沒有真的去看過任何一個使用者的操作行為。它寫出來的文章，讀起來通順、結構完整、甚至有點像專家，但骨子裡回答的是「它猜你會問的問題」，往往跟「你真的在問的問題」對不上。這個落差，就是那九成拿不到流量的內容共同的特徵。把設計思考的同理放回內容生產的第一步，你做的不只是寫一篇文章，你是在建立一種 AI 複製不來的、來自第一手接觸的經驗，而這種經驗，正是搜尋引擎與讀者這幾年都越來越在意的東西。

落實到執行面，你可以把設計思考的五個轉換點，直接對應到一套內容生產的流程。

設計思考步驟	對應的內容／行銷動作	產出
同理	研究搜尋字詞、看真實提問、讀留言區與論壇	一批「搜尋者在煩惱什麼」的具體情境
定義	把零散字詞收斂成三到五個核心搜尋意圖	這頁內容鎖定的核心問題
發想	針對每個意圖，產出多種可能的切入角度	一籃子可選的標題與章節方向
原型	先寫大綱與前兩百字，不寫全文	一份可被快速否決或調整的草骨架
測試	用搜尋結果頁與讀者行為數據驗證命中率	修正後的內容與下一輪的洞察

用這個流程去想內容，你會發現「寫文章」跟「做產品」有相通之處：都是先同理、再定義、再發想、再做原型、再測試，然後繞回去。內容可以用大綱當原型，測試則看 Search Console 的曝光與點擊、頁面互動和讀者回饋；單一排名或停留時間都不足以判定內容品質。如果你想把它落實成一套完整、可重複執行的內容生產體系，我們的內容行銷策略全攻略有更展開的步驟；而如果你要把「同理搜尋者」這一步做得更技術性，例如把搜尋意圖落實到標題、內文、內部連結的具體優化，可以接著讀站內 SEO 終極攻略，把設計思考的同理心接到一套可執行的優化檢查表上。

一份能立刻開跑的設計思考工作單（六個動作）

讀到這裡，你手上的觀念已經夠用了，接下來的差別全在執行。把整篇文章收斂成六個你這週就能做的動作，按順序走一遍，就是一個完整的設計思考小循環。

1. 挑一個你目前最不確定的產品假設。不用挑最大的專案，挑那個你心裡一直覺得「應該是這樣吧，但說不上來為什麼」的假設。設計思考在「不確定」上才發揮得了價值。
2. 找三個真實使用者，做現場觀察。不要發問卷。約三個人，在他們真實使用的場合，看著他們操作，問他們行為層的問題（你上次是什麼時候遇到、你接下來做了什麼）。
3. 把觀察收斂成一句問題陳述。用「某類使用者、在某個情境下、想要完成某件事、但被某個東西卡住」這個格式寫。寫不出來，就代表你還沒挖到動機層，回去再挖。
4. 在四十分鐘內產出三十個解法點子。套用前面講的護欄，禁用「但是」，鼓勵荒謬，量產與評估嚴格分開。
5. 用紙筆或最簡單的工具，做一個夠醜的原型。只驗你現在最不確定的那一個假設，其他細節全部用假的、用畫的、用佔位字。原型越醜，回饋越真。
6. 拿原型給三個人用，只觀察行為。給任務不給路徑，請他們出聲思考，記錄他們猶豫與卡住的瞬間。這些瞬間就是你要帶回下一步、甚至繞回第一步重新同理的訊號。

這六步走完，你不會得到一個完美的產品，但你會得到一個「被真實行為修正過」的方向。而那個方向，比你在會議室裡推測出來的任何方向，都更值得你投入後續的資源。

設計思考是一種檢驗自身假設的紀律。它不保證做出成功產品，但能讓團隊在投入大量成本前，先排除部分不成立的方向。把它跟行銷、SEO 接起來看，核心動作相同：先釐清對方要解決的問題，再動手做，並用測試結果持續修正。