一個很常見的場景
我請一位工程師用角色代入的方式重新看一遍需求。
他照做了。他很認真地想，也寫了一份東西給我。裡面確實提到了使用者、提到了操作情境、提到了他認為使用者會需要什麼。
但整份東西，從頭到尾都是上帝視角。
更麻煩的是，他不知道。他不是敷衍，也不是抗拒，他是真心認為自己剛剛做的那件事，就叫做角色代入。而且看起來，他已經這樣認為很久了。
問題不是「做不到」，而是「以為自己做到了」
如果一個人說「角色代入對我來說很難，我不太會」，這其實是好處理的。他有自覺，你可以給他框架、給他案例、給他回饋，他知道自己在進步還是沒進步。
難處理的是另一種：他心裡有一套「這就是使用者角度」的定義，那套定義從來沒有被檢驗過，而且很可能已經產出過很多份規格、得到過不少認可。因為表面上看，他確實有在「思考使用者」，只是那個思考的引擎，從頭到尾都是工程邏輯，只是換上了使用者的語彙。
這種狀況，你不是在補一個洞，而是要先讓一個人看見：他原本以為對的東西，其實是錯的。
幾個可以自我檢查的徵兆
假代入之所以難以察覺，是因為它長得很像真的。以下幾個徵兆，是我覺得比較好辨識的破綻：
描述需求時，主詞是系統，不是人。
「系統應該要擋掉這種情況」「邏輯上這裡要先判斷」——這些都是從系統內部往外看。真正的代入，主詞會是使用者：「他這時候會看到什麼」「他在這裡會不會知道自己該做什麼」。
解釋設計決策時，理由永遠是「合理」而不是「好用」。
「這樣比較嚴謹」「這樣比較好維護」「這樣邏輯比較一致」——這些都是對的，但它們回答的是工程問題，不是使用者問題。如果一個人解釋十個決策，十個理由都在這個範疇裡，那他思考的對象從來就不是使用者。
被問到「使用者當下知道這件事嗎」，答案是「應該知道吧」。
這個「應該」是最明顯的破綻。因為它代表回答的人，是用自己的全知去推測別人的認知邊界。真正代入過的人，會清楚知道這個角色手上有什麼資訊、沒有什麼資訊，答案不會是「應該」。
用第三人稱在想，而不是第一人稱。
「使用者應該會希望……」這種句式，本質上還是旁觀者在猜測。真正的代入是第一人稱的：「我現在要做的事情是……我現在卡住的地方是……」。句式不同，思考模式就不同。
為什麼會這樣？這不是態度問題
我想強調的是，這件事很少是因為誰不用心。它背後有幾個結構性的原因：
第一，知識的詛咒。
一個人一旦知道系統怎麼運作，要他假裝不知道，是違反大腦運作方式的。而諷刺的是，最常被要求做角色代入的人（資深工程師、最懂系統的人），剛好就是受這個詛咒影響最深的人。這是認知結構的限制，不是努力程度的問題。
第二，「站在使用者角度想」這句指令，本身就沒什麼用。
它只有九個字，聽起來很輕鬆，但它沒有給任何邊界。這個角色是誰？他知道什麼、不知道什麼？他現在的處境跟情緒是什麼？沒有這些限制條件，一個人很自然就會退回自己最熟悉的視角，也就是全知視角。指令的簡潔，掩蓋了背後需要的準備量。
第三，這件事沒有驗收標準。
use case 寫錯了，邏輯不通，看得出來。規格漏了流程，測試會抓到。但「你代入得夠不夠深」這件事，沒有格式可以對照、沒有人會說你錯，甚至連自己都判斷不出來。一個沒有回饋機制的能力，人是有可能用錯誤的方式做上好幾年的。
這為什麼重要
有人可能會說：需求分析是 PM 的事，工程師照規格做就好。
但實際開發的時候，規格永遠有縫隙。這個欄位留空要顯示什麼、這個 API 逾時使用者該看到什麼、這兩條規則衝突時誰優先——這些問題每天都在發生，而當下做決定的人是工程師，不是 PM。那些決策點，根本沒有機會回到需求端被審視。
所以如果角色代入這一步是失真的，後面再嚴謹的 use case、再完整的規格文件，也只是把錯誤的假設包裝得很整齊而已。
我自己的理解是：產品初期的需求分析，訂的是方向；工程師落地時做的，是把方向導正成真實路徑。兩者用的是同一種能力，只是解析度不同、發生的時間點不同。前者是巨觀的代入（這群人整體要什麼），後者是微觀的代入（這個人在這一秒、這個畫面下會怎麼反應）。
這也解釋了一個很常見的現象：方向明明沒錯，成品卻走鐘。因為使用者感受到的，從來不是方向對不對，而是無數個微觀決策累積出來的體驗。
所以，這是基本功
我一開始以為角色代入是一件很基本、很理所當然的事。後來才發現，它確實很基本，但一點都不簡單。
問題出在我們對「基本功」的直覺理解——我們常常把「基本」等同於「簡單」，但這兩件事從來就不是同一回事。
橫豎撇捺是書法的基本功，但寫好一橫要練很久。蹲馬步是武術的基本功，但蹲得標準、蹲得住，才最見真章。練音階是音樂的基本功，卻也是最容易看出程度差距的地方。
基本功之所以是基本功，是因為它使用頻率最高、影響範圍最廣、是所有進階能力的地基。正因為它離核心最近，反而最難精通，也最容易被輕忽。
基本功難，才是基本功的常態，不是例外。
而角色代入最難的地方，或許不是學會它，而是發現自己其實還沒學會。
