作為一名體驗設計師，和產品對接的過程中，經常會出現一些分歧，那么應該用什么方法去解決分歧呢？我總結了“場景還原”和“獨立思考”以下兩個方法，通過這兩種方法的運用，我不但和產品經理的分歧變少了，也對需求和業務的理解更加深刻了。

更多需求溝通方法：

方法一：場景還原

作為一名體驗設計師，在日常產品需求對接中，我們的正常流程是：由產品經理發起需求，撰寫 Prd 文檔，然后輸出給交互設計師，交互設計師補充原型設計等，原型設計完成后輸出給 UI 設計師，UI 設計師輸出視覺 UI 圖，剩下的步驟就是交給程序開發同事，最后 PM、設計師驗收上線，運營同事開始做用戶運營等。這是一個正常的產品需求對接流程，簡單來說就是產品經理提出需求，剩下的同事角色配合產品經理完成需求。

現在我們想一下，產品經理的需求怎么來的？誰給產品經理提出需求？產品經理可能回復說是業務方提出的需求，那么誰才是業務方？是老板、直屬領導、市場/運營同事、還是產品經理對用戶的調研、數據分析后的結果？無論是哪種來源的需求，產品經理都需要輸出 prd（產品需求文檔），最后這個 prd 文檔就是產品經理對用戶和場景的分析后的產出，也就是說產品經理做每個需求之前，已經有了明確的使用場景后才輸出 prd 文檔。

當然了，上面這是一種正常的對接狀態，既然有正常對接狀態也就會有非正常的狀態。打比方說：有些產品經理沒有做用戶和場景的調研，只是從自身角度出發，我認為用戶的使用場景是這樣的，根據自己所認為的結果直接輸出 prd 文檔。最后導致與有些不太“謹慎”的產品經理提出的需求沒有充分考慮用戶場景，出現了一些不正常的需求。典型的例子就是，之前微博上瘋傳的某位產品經理要求用戶 app 主題顏色能隨著手機殼顏色自動調整，開發和產品經理打架，上了微博熱搜的這條八卦新聞。

所以，為了我們體驗設計師能更好的理解這個需求背景和目的，我們拿到需求以后，可以問產品經理一下問題：

這個需求的目的是什么？

這個需求的目標用戶是誰？

這個需求需要解決的用戶痛點是什么？

這個需求給用戶帶來的價值是什么？ 這個需求給平臺帶來的價值是什么？

這個需求的使用場景是什么？

這個需求的盈利模式什么？

如果我們和產品經理充分了解溝通以上問題后，相信產品經理也不會提出“要求用戶 app 顏色能隨著手機殼顏色自動調整”這種需求吧。

總結一下：我們接到需求以后，首先要了解用戶，場景和要解決的問題，然后思考是否能找到應用場景？我們為什么要做這個功能？使用場景是什么？解決的問題是什么？都充分的問清楚了，可以做，那么我們就開始做。假如找不到應用場景，那么就可以判斷這是個偽需求，優先級不高的需求，可以考慮不做或者是排期靠后再做。

例如：美團外賣 app 的產品經理開需求評審會，要加一個“多人拼單”的功能。多人在某家外賣餐廳一起點餐，大家點的餐都加入到同一個購物車里，然后統一一個人支付，最后一起送來。我們接到這個需求后，了解用戶，場景，問題后，開始還原用戶使用場景。針對這個需求開始思考，既然是拼單，肯定是多個人一起點餐的場景，什么時候才會出現多人一起點餐的場景？

1. 工作日午餐。
2. 聚會的時候。
3. 加班，老板請客。

我們找到了場景，開始思考用戶真的會按照我們設想的拼單去點餐么？

1. 工作日大家點餐，直接問同事你想吃什么，直接幫他點了付款，然后微信轉我飯錢不就可以了？為什么還得那么麻煩，分享個鏈接，讓他自己點？
2. 拼單是針對于單獨一個餐廳，這家餐廳飯菜種類有點少，聚會的時候由于人比較多，大家口味都不太一樣，你想吃烤鴨，我想吃紅燒肉，他想吃烤串，這種場景下怎么拼單？
3. 晚上加班，老板請客？試想一下，老板真的會問我們想吃什么？然后把鏈接甩給我們，一起拼單么？一般不都是老板直接買好了，群里通知一聲加班餐來了，大家快來吃吧。就算老板把拼單鏈接給我們，也會讓某個人統計你吃什么，我吃什么，讓這個人統計好以后直接點餐。

回到最初的場景還原，我們找到了用戶使用場景，但是用戶不會按照我們的想法來使用這個功能，那么這就是偽需求，可以不做或者排期靠后做。

最后當我們判定這是偽需求的時候，直接說這需求場景不明確、不成立，我們設計不做，這么說我們可能又要和產品經理“撕逼”了，那么我們該怎么說出這個需求不成立呢？

首先尋找使用場景的時候，把場景一一列出來。然后根據列出來的每個場景講故事，以講故事的方式反饋給產品經理。

例如：中午吃飯點外賣，我們一般都是直接問同事，你吃什么？我幫你點了吧，或者是把點外賣的手機給他，讓他自己選，最后我付款一起送來，同事微信轉我飯錢。

再舉個例子：你和女朋友在不同的公司上班，白天你倆正在各自公司上著班呢，你正在開心的摸著魚中，突然你女朋友給你發微信說：我肚子疼，很難受。這時候你會用拼單的功能么？

我們場景還原一下。這時候你會怎么做？

1. 首先安慰一下對方，表示一下關心。然后問她想吃點啥？打開美團外賣幫她點杯奶茶。
2. 直接發個大紅包。
3. 直接幫她點她喜歡吃的。

通過上面這兩個場景的分析，我們可以分析出在這兩種場景下，我們不需要拼單這個功能。
那么為什么外賣 app 上還存在拼單功能呢？拼單功能有什么價值呢？既然上線了，那么就有其使用的場景，我們剛才的分析只是沒有找到對的拼單功能使用場景，那么拼單功能的正確使用場景是什么呢？思考一下。

公司周邊就這么幾家餐廳或者就這么幾家比較好吃的餐廳，大家都經常點這幾家餐廳的外賣，為了省配送費，和同事可能會點同一家餐廳。最后定義需求的場景是：“為了省配送費，才會用拼單功能”。

再舉個例子：語雀協同功能。

通過語雀員工寫的文章分析可以看到，語雀現在已經有上千萬用戶，50 萬+的協同組織用戶，然而使用文檔協同的人數不足 5%，剛開始的時候語雀沒有做文檔協同，但是后來還是做了這個功能，為什么做這個功能呢？我們試著場景還原分析一下。

首先我們要了解到有 50 萬+組織用戶，現在要解決這些組織成員協同辦公寫文檔的場景。解決的方法就是文檔協同，那么什么時候才用協同功能呢？

1. 每周開周會之前，大家需要把自己的進度及時同步到進度文檔中。
2. 大家需要在同一個文檔中寫出這周所工作的內容和個人思考。
3. 需求較多，設計部同事需要知道每個人工作排期。

有了場景我們開始分析

1. 同步進度，假如我們都把自己的進度情況單獨發給領導或者群里，領導整理起來是不是很麻煩？效率很低？
2. 如果我們把自己的工作內容都發給同一個人，那么整理起來是不是很費時間？很容易亂？內容沉淀下來很麻煩？
3. 需求太多，排期很重要，大家都在一個文檔填寫自己的排期這樣更高效便捷。

通過上面的場景還原分析，用戶會用協同的功能么？對比傳統的 Office 工具，協同功能確實很實用、也很方便，用戶會按照語雀所設定的功能去使用。所以呢，就算只滿足了 5% 用戶的協同需求，那么這個需求就是有價值的，所以最后語雀還是做了這個功能。

總價一下。我們拿到需求后，也找到了用戶的使用場景，怎么判定這個場景合理不合理呢？我們可以從用戶，目標，行為，媒介，環境來做對比，把場景一一列出來，用講故事的方式把場景一一講出來，還原正確的用戶使用場景，最后對需求做出正確的判斷。

方法二：獨立思考

先分析一下什么是獨立思考？獨立百度百科的解釋：單獨的站立或者指關系上不依附、不隸屬，依靠自己的力量去做某事。那么怎么理解獨立思考呢？獨立思考就是依靠自己的思考去分析某件事，對你接受到的每個信息都保持質疑，對每件事都有自己的判斷和思考，只相信自己判斷甄別后的結果。

獨立思考是一種思維模式，有了獨立思考就像打通任督二脈，進步飛快。

例如：我說大海都是藍色的。有獨立思考的人當聽到我這句話的時候首先要質疑我，大海都是藍色的么？他會去調查，搜集資料甄別大海是藍色這個信息，通過分析發現有些地方的大海海灘是粉色的？他先質疑了我想法，然后搜集信息全局思考，最后發現真相，大家不僅僅只有藍色，也有其他的顏色。

這個過程就是獨立思考的過程，可以總結一下：1、先質疑。2、搜索信息，思考。3、得出真確的答案。

體驗設計師工作中的獨立思考是什么呢？

日常的產品需求對接中，產品經理發現了問題，最后也給出了的 prd 解決方案，沒有獨立思考的人會直接按照 prd 方案開始陷入細節，直接開始設計。有獨立思考的人會怎么做呢？我會先質疑這個方案，然后收集資料思考，最后給出解決方案。當你開始質疑的時候，也就意味著你進入了獨立思考的狀態。

這里說一下“抬杠”和“獨立思考”的差異。

工作中可能對某位同事之前有過一些誤會，他說的任何需求你都認為是錯的沒有價值的，這是抬杠。

工作中無論對方是誰，針對他的話進行質疑，思考一下對不對，最后給出結論，這是獨立思考。

例如：拼多多早期假貨泛濫，大家都在調侃拼多多是拼夕夕，但是過去兩三年，拼多多通過百億補貼、簽約品牌形象店等操作，改變了人們最初對拼多多的認知。這時候你準備在拼多多買一部手機，身邊有人建議你別在拼多多買，去京東買，拼多多都是假貨。這時候首先我要質疑，拼多多都是假貨嗎？然后打開拼多多看到百億補貼，翻了翻評論，大家都在說真香，最后得出結論，發現拼多多不止只有假貨啊，也有很多正式的店鋪嘛。這就是典型的獨立思考過程。

再舉個例子：滴滴當剛對外推出的時候，大家都沒有搭乘陌生人汽車的習慣，對于這種新的交通出行方式有些不適應，滴滴為了保證用戶的出行安全，降低用戶對安全的擔心，做了一個乘車之前需要打開 app 掃描一下司機師傅的臉，看看是不是車主本人。滴滴花了大量的人力物力去解決人臉識別的問題，也花了大量的財力去做宣傳，最后發現大家并不買賬，哪里出現了問題呢？

產品提出需求后，開發同事開始思考技術的實現難度，運營同事開始思考運營策略，那么我們設計師就要承擔還原用戶場景的責任，用獨立思考的方式去思考按照產品的方案，到底能不能解決用戶對安全性擔心的問題？很顯然，上車后掃描司機師傅的臉是個偽命題，晚上加班后打車回家，上車后先掃描師傅的臉？車里光線那么暗，你還著急回家，這時候不掃師傅的臉不匹配，這種場景合適么？就算是白天乘車，用戶拿著手機去掃一個陌生人的臉，用戶和死機師傅尷尬么？后來滴滴就取消了這個掃師傅臉的功能，反而直接是看實際乘坐車輛的車牌號是否和打車車牌號一致，司機師傅校對乘客手機號，匹配上后就可以直接上車了。基于這個案例，我們接到需求后，先質疑，掃臉真的能解決用戶對安全性的顧慮問題么？然后我們去做場景還原，發現掃臉這個解決方案并合適，最后給出判斷。這就是我們獨立思考的過程。

再舉個例子，最近我想買一個 iPad 二手鍵盤，在閑魚上搜索后和一位小伙伴交流很愉快，于是開始見面交易，見面后，我在閑魚付款，他點擊發貨，不到一分鐘我點擊確認收貨，這時候出現了風控的問題。正常來講，我已經確認收貨，資金應該直接到賣家支付寶，但是由于發貨和確認收貨時間間隔過短，閑魚判定買家受騙，資金凍結，賣家拿不到錢。過了幾分鐘，有個杭州電話打來詢問我是否收到貨？直到我回復確認收到貨物以后，資金才到賣家賬號。通過這個小案例，我們分析一下產品需求的場景。

首先要確認場景：賣家發貨時間和買家收貨時間間隔過短，閑魚平臺判定為風控交易，凍結資金。什么時候才會出現這種情況？

1. 買家被騙，根據以往被騙的案例判斷，賣家忽悠買家必須先確認收貨才可以進行交易。
2. 買家被賣家恐嚇，早年閑魚中關村見面交易幾乎都是騙子，賣家強迫買家確認收貨，最后買家錢花了，貨沒拿到。

基于以往買家被騙的案例，為了減少買家被騙事件的發生，產品經理就把這種場景判定為風控交易，打電話給買家二次確認后才把資金給賣家。我們思考一下，首先質疑這種場景存在么？確實存在，新聞上確實也看到過這樣被騙的案例，這個需求是成立的，有價值的，這個需求值得做。

總結一下獨立思考的過程就是：先質疑，質疑對方說的話對不對，成立不成立？然后整合線索，全局思考，定義問題，最后得出正確的答案。

最后我們思考一下：在一輛 7 座 中大型 SUV 車中，智能車艙（HMI）副駕駛位置添加一塊大屏幕，作為副駕駛的娛樂屏，這個需求是否成立？

總結

雖然本文寫的對接場景有些理想化，在日常的工作需求對接中，根本沒有時間讓設計師們去思考，一般情況下需求來了，設計師作為執行把 UI 畫好看就行了，通過我以往的工作經驗認知，沒有思考的執行，就是停滯不前。我記得之前周陟老師說過：同樣一張 UI 頁面，新手只是看到了圖標的好看與否，高級設計師看到了背后的交互邏輯，而專家設計師看到了背后的運營策略以及對平臺產生的價值。為了能更好的提高我們對需求和業務的理解，我們應認真對待每次需求，再小的需求也有它可研究的價值。

本文介紹的兩種方法：場景還原、獨立思考，不僅僅運營在工作中，在生活中也特別實用，對待每件事情都要有自己的觀點和看法，有自己的理解，就算當時理解是錯的，隨時思考的深入，慢慢也會發現真相。

最后，加入您看完本文認為對自己有一些幫助，請把本文分享給自己的好友，謝謝。