2021-2-22 資深UI設計者
在工作中，我們會經常與產品經理對接需求、理解需求，站在交互設計師角度，我想分享如何分析需求，如何解決正確的問題。
這里的需求指業務需求，即現狀無法滿足需要，從而為達到某種目標而制定的。需求主體未必只有用戶，也可能是企業、產品、運營、技術。
需求可以大致分類兩大類，內部需求和外部需求。
內部需求即由企業內部發起的，基于企業、產品本身商業（產品、運營）、體驗（設計、技術）等層面的訴求而提出的。
產品的需求：由產品側發起，最為常見，通常基于對產品發展目標、商業目標、競品動向、行業變化等層面考慮的需求。
運營的需求：由運營側發起，通常基于運營活動、玩法等層面考慮的需求。
設計的需求：由設計側發起，通常基于對體驗、視覺等層面考慮的需求。
技術的需求：由技術側發起，通常基于對產品技術體驗、性能優化等層面考慮的需求。
領導的需求：由公司上層發起，一般與產品經理發起的需求類似，但有時也可能臨時想法。
···
外部需求即所有在企業以外發起的，基于對企業產品的訴求、要求得不到滿足而提出的。
用戶需求：主要來自 C 端產品，用戶對于產品的反饋，或企業對用戶的調研而得出的需求。
客戶需求：主要來自 B 端產品，客戶對于產品功能、性能等層面考慮的需求。
政策需求：主要來自相關政策法規，通常基于對產品合規性、用戶隱私權限等層面進行規范要求而整改的需求。
···
以上列舉的是常見的需求類型，可以發現需求類型其實是多樣的，設計師對于需求類型的鑒別也需要有一定的認知。
在互聯網公司中，常見的職能角色主要有：產品經理、交互設計（主要分布在中型、大型互聯網公司）、UI 設計、研發、測試。但除了產品經理之外，設計師對于需求分析的了解也有很大的必要性。
上面提到，產品是需求的主要發起者，所以理所應當有很大一部分工作量就是需求分析。設計師的工作，最常見的就是對接需求，然后將需求轉化為設計。而這個流程中的關鍵點，就是作為交互、UI 設計師，應該如何正確的分析需求。
有人說，分析需求不是產品經理的事情嗎？交互設計師只要會畫框架框架不就行了？如果這么想，那是還沒有對“分析需求”本身有足夠清晰的認知。
如果從用戶體驗五要素的層面對需求分析進行劃分，可以發現：
戰略層告訴我們“什么是產品目標、用戶需求”
范圍層告訴我們“什么方式、內容、功能可以滿足需求”
結構層告訴我們“如何分布這些滿足需求的內容、功能“
框架層告訴我們”如何設計這些滿足需求的界面框架、信息呈現”
表現層告訴我們“如何設計符合產品定位、風格、需求特征的最終展示外觀”
產品經理的需求分析：側重于從商業維度考慮產品目標，考慮用戶的需求是什么，以及用什么樣的東西去滿足用戶需求。
設計師的需求分析：更側重于基于對產品需求的正確理解，從用戶、商業的層面考慮，并采用合適的設計形式來實現。
在體量較小的公司，產品經理會肩負需求分析、交互設計等工作。而在體量較大或者更重視用戶體驗的公司，設計師則可以更加聚焦于如何權衡商業與用戶體驗。
這時，擺在產品經理與設計師面前的會有 2 道鴻溝：
產品經理是設計師最常見的需求對接者，基本上是產品經理發起需求，設計師執行。這個過程是先后關系，大部分情況下也是單向傳遞的。
當產品經理比較強勢時，即使設計師對需求有疑問，也只能當成意見補充，而是否接受很大程度上是產品經理決定。這里面的溝通很關鍵，因為這條鴻溝決定著設計師是否能夠正確理解需求背后的本質，理解本質需求就是跨越這條鴻溝的橋梁。
正確的溝通姿勢是理解需求的第一步，而這一步基本定義了整個交互、UI 的設計走向，需求目標會影響設計師的思考方式，當沒有將需求目標透徹理解時，會使思考方式嚴重受限，比如產品需求是讓設計一個彈窗，設計師就原原本本的設計一個彈窗，而不去思考為什么要設計這個彈窗。
我們該如何正確理解需求？
產品輸出需求文檔的時候，大多會輸出初步的交互框架想法或者視覺設計建議，但在需求溝通時，最關鍵的一點是關注本質需求，避免一開始就陷進具體的需求細節。這里并非說產品提供的方案不好，事實上，有時交互方案與產品提供的方案一致，這是不可避免的，當目標相對清晰的時候，不需要為了特地設計而設計。
但是，如果溝通需求時，過于關注細節，容易導致看不清需求的本質。所以，當與產品經理溝通時，可以多問問為什么要做這個需求，是為了達到什么目標，滿足什么需求，然后從交互體驗、創意性等角度出發，思考更好的交互方案。
無論是內部需求還是外部需求，一般都會匯總到產品經理，再由產品經理與設計側以及其他職能同事對接。需求來源多樣，特別是用戶需求，我們都知道用戶表達或反饋的需求未必是用戶的真實需求，所以在溝通時，應該甄別哪些需求不合理。設計師有用戶體驗的立場，站在不同立場上，往往可以發現不同的問題，將問題在需求階段暴露出來，避免執行過程反復調整。
產品經理與設計師職能不同，所以立場、關注點都會有差別。
首先，我們需要接受產品經理與設計師的意見是一定會產生沖突的，所以不要覺得為什么與產品經理怎么總是意見不合。
其次，站在雙方的共同目標都是讓產品變得更好的角度，我并不認為意見沖突是不好的，相反，這是在前期基于雙方不同立場對于需求本身合理性的充分討論，達到雙方都認同的意見，然后共同將產品做好。
如何跨過產品經理與設計師意見沖突的鴻溝？
要看清這個問題，需要回歸到產品經理與設計師立場的差異上，設計師習慣性的會站在用戶體驗的角度上思考問題，也往往需要為體驗負責，而產品經理需要考慮更多產品策略方面的問題，有業務的 KPI。
在溝通需求時，雙方意見不合主要是關注的目標不一致。這時，設計師不該只從體驗好與不好、這么做好不好看的角度出發思考問題，而是需要基于用戶體驗并在理解商業目標的基礎上進行溝通。作為設計師，不能盲目接受需求，更不能盲目拒絕需求。
不同企業的產品流程會有一些差異，但大部分是產品需求過了幾輪評審之后，流轉到設計。此時就算設計師對需求有不同意見且產品也同意調整，在某些情況下也可能造成項目延期的風險。
如果條件允許，設計師可以提前介入到需求評審階段，即在需求評審初期可以表達設計側對需求的看法，而需求評審可以充分進行需求討論。此外，某些產品需求（比如要求較多的設計創意發散）可能會強依賴于設計、動畫等職能角色參與，提前介入可以在需求前期有充分表達設計觀點的機會。
5W1H 分析法也叫六何分析法，是一種思考方法，也是工作方法。可以幫助我們避免只關注某個細節或者具體的需求方案，而是從頂層開始思考的方式。
大部分人都聽過這個方法，但是日常工作中不太知道應該如何使用，個人理解，這個方法在很小的需求方面不太適合。但是在處理比較中型/大型的需求、設計師對需求本身疑惑時、甚至與產品經理意見分歧時，有很大的用處。
需求的背景是什么，產品在當前遇到了什么問題，比如數據差、體驗反饋差等。
想要達到什么目標，是商業需求還是用戶需求？
產品所在行業的競品情況如何，市場趨勢如何？
需求的內容是什么，基于需求的背景、目標，產品即將做什么事情？注意不能局限于做某個具體形態的事情，可以嘗試描述這件事情如何滿足需求。
什么場景出現這個需求？
需求的最終產物會在什么場景/頁面/模塊出現？
什么時間節點出現這個需求？
需求的最終產物會在什么時間節點出現？
產品的用戶是誰？這個“誰”不是只某個個體，而是產品的某類典型群體。
用戶需求是什么？用戶遇到了什問題？可以將用戶需求枚舉出來，但是需要注意用戶需求不一定等于產品需求。
需求所要做的這件事情，實現方式是怎么樣的？
有沒有其他可能的方式可以更好的實現這件事情？
思考產品提出的需求建議方案，與需求目標是否一致。設計師理解并同意以上拆分的結論，那就證明需求本身層面是沒有異議的，接下來就是需求實現層面的問題了，此時設計師的工作，就是思考是否還存在更好的實現方式能夠滿足這個需求。如果以上問題不夠明確，那么可能需求本身可能有值得商榷的部分。
以需求目標為導向，是判斷方案是否可行的最直接方法。這種溝通方式，可以幫助設計師與產品經理構建相同目標、場景等變量信息，幫助產品經理與設計師對齊設計目標，減少后續方案返工的情況。我們通過梳理這些信息，盡管未必能夠馬上思考出方案，但是能夠初步判斷哪些方案可能不太合適。
以上是對于 5W1H 的基本拆解，下面我會嘗試舉一個虛擬例子進行解釋。
某天，產品經理提了一個需求：
需求內容：
優化用戶取消訂單的挽留彈窗。線上的樣式是底部彈窗，但是底部彈窗容易點擊“取消訂單”按鈕，且文字提示不夠清晰。初步方案是將彈窗樣式改成居中彈窗，對于用戶提醒層面會更加明顯，如下圖：
你覺得很奇怪，把彈窗從底部改為居中樣式，盡管提示更明顯了，但是真的能夠降低用戶的取消率嗎？實際上，你甚至不清楚這個彈窗對于用戶是否有幫助，也不清楚是否能解決需求的問題。你可能會思考，假如你是用戶，會因為這個彈窗就不取消訂單嗎？
很多產品都會設計頁面退出時的挽留彈窗，常見的如“確定退出頁面嗎？ 退出/取消”，但這經常是一種為了做而做的挽留彈窗。對于這種彈窗，是否可能不僅不能帶來目標效果，反而容易引起用戶的反感。
我們在分析需求時，可以嘗試簡單拆解一下這個需求：
需求的背景：行業內，用戶下單之后都有取消訂單的操作，本平臺的訂單取消率處于行業中的平均水平，基于對產品的優化，希望可以降低訂單的取消率。
通過某種方式，降低訂單取消率。目前比較合適的方式是優化取消訂單的挽留彈窗。
我的訂單頁，目前其他場景無法取消訂單，所以場景比較明確。
用戶已經下單（已支付/未支付）之后，點擊【取消訂單】按鈕后觸發挽留彈窗。
目標用戶：已經下單的用戶。
用戶需求：枚舉用戶遇到的問題，如：點錯了、忘記支付密碼、不想買了、收貨地址填錯了、其他原因…
初步想法：把底部挽留彈窗改成居中挽留彈窗。
其他想法：是否還有其他方式降低取消率？
你會發現，這個需求其實是可以被拆解的。在這個需求里，你會發現，盡管原因（Why）很清晰，但是用戶（Who）是推導出來的結論方法（How）是有些問題的。當從用戶角度出發 ，僅僅一個居中挽留彈窗是無法解決用戶需求的。
這里需要警惕一個點，即設計“挽留彈窗”這件事情，先不管最終產物是不是一個彈窗的形式，但是不能一開始就陷入“我要設計一個彈窗”的思維，可以先思考下，我需要通過什么方式降低用戶的取消率？
但是我們如何發現潛在的更優方案呢？
可以嘗試多幾個問號：用戶為什么會取消訂單？設計挽留彈窗，是否就真的對降低取消率？設計挽留彈窗，能否解決用戶在這個場景遇到的問題？是否可能不用挽留彈窗降低取消率？
通過上面用戶需求列舉，你可能會發現部分取消訂單原因，是不需要用戶取消了訂單才能解決的，比如“地址填錯了”，并且這部分用戶在本平臺訂單取消率中占了一大部分。
這時需求的解決方式，可能變成：
· 通過向用戶提供修改收貨地址的入口降低訂單取消率。此時彈窗的動機不再是為了“阻擋”用戶，而是推測用戶操作意圖，幫助用戶解決問題。相比于單純的阻擋彈窗，這種處理方式的好處是：通過找到并解決部分操作的根本原因，以減少負向操作，幫助平臺更好分析用戶取消訂單的原因以改善產品體驗；
· 如果填錯地址的用戶占了訂單取消率的很高比重，是否可能嘗試優化下單流程？比如將讓用戶更明確感知訂單地址，避免用戶選錯地址。從而通過優化本質的問題，減少用戶取消訂單的比例，也減少彈窗出現的頻次。
最后你會發現，設計出來的方案可能會以彈窗作為表現形式，也可能通過優化下單流程降低取消率。這個方法主要是將需求梳理清楚，讓我們明確這個需求的來龍去脈，減少遺漏的問題。
2005年，英國設計協會（the British Design Council）首次提出這種雙發散—聚焦設計模式，被稱作雙鉆設計模式（double-diamond design process model）。英國設計協會將設計過程分為四個步驟：“發現”和“定義”，確認正確問題的發散和聚焦階段；然后是“構思”和“交付”，制定正確方案的發散和聚焦階段。”
迄今為止，我們其實可以看到許多設計方法，這些方法可以讓我們避免從初始問題直接思考解決方案，避免因為忽視真正的、根本的問題而設計價值不大的設計方案。雙鉆設計模式，與上面的 5W1H 分析法都是屬于設計分析方法，也同樣可以幫助我們如何分析需求、拆解需求、解決正確的問題。
設計師在需求分析過程中，要明確需求是某種方案，但未必是最終結果。盡管從效率層面看起來像是在倒退，因為明明產品經理已經提供了方案，而設計師還要重新思考。但實際上，這種思考方式，恰恰可以避免局限于某種職能視角思考問題。
1、設計師會先質疑問題，接著擴大問題的范圍，思考問題之下隱藏的根本原因，接著聚焦于其中某一個問題的描述。
2、在思考解決方案階段，會先擴展可能的方案，再進行一次發散思考。最后，將這一切重歸于某個合適的方案。
拿到問題——發散——聚焦——發散——聚焦，看起來像是兩顆并列的鉆石，所以稱作雙鉆模型。
對現狀進行深入研究。包括了解用戶特征、產品當前狀況、用戶如何使用產品以及用戶對產品的態度、競品現狀等，此時我們不會將聚焦于某一個問題，而是窮舉盡可能多的潛在問題。
確定關鍵問題。這一階段，我們關注的焦點是：用戶當前最關注、最需要解決的問題是哪些，需要根據團隊的資源狀況作出取舍，聚焦到核心問題上。
尋找潛在的解決方案。在方案發散階段，我們不需要過多考慮技術的可實現性。
把上階段所有潛在的解決方案，逐個進行分析驗證，選擇出最適合的一個或多個方案。 我認為在這個階段，設計師可以盡可能地發散想法，但是就絕大多數國內企業、產品現狀而言，很難將多種想法一一嘗試，因為開發成本、項目時間等問題，可能導致投入產出比不高的情況，所以設計師應該提升對好方案的判斷能力。
我們該如何使用雙鉆設計模式，同樣在此我會舉一個虛擬例子進行解釋。
你們是內容資訊類產品，某天，你接到一個需求：
需求內容：
優化某應用 App 首頁搜索欄，包括將搜索欄高度加高、設計顏色更加明顯，以提升搜索欄的點擊率。
需求背景：
對比了同行業競品，發現競品的搜索欄點擊率比我們高了20%。我們的搜索欄點擊率為 5%，而競品為 20%。同時，通過對比發現，競品搜索欄高度更高，搜索欄顏色更加明顯，除此之外，頁面其他信息區別不大。
初步分析：
這個需求問題很明確，就是我們搜索欄點擊率比競品低。但這個問題歸因真的全因搜索欄高度、設計樣式的影響嗎？
其實未必是這個原因，搜索欄的點擊行為本身更傾向于目的性點擊，也就是說有相對明確的目的去點擊，而目前高度雖然不高，但是足夠明確。
通過雙鉆模型“發散——聚焦”的分析和驗證，我們發現最終解決方案不僅僅是最初的方案，這四個階段不是孤立存在的，而是彼此聯系。當然這種舉例是為了更加便于理解，實際項目中一定會遇到很多問題是很復雜且很難順利解決的。但是這種設計模式幫助我們減少用局限性的眼光進行設計，發現正確的問題，發現正確的解決方案。
有人這么解釋：以事物的結構為思考對象，來引導思維、表達和解決問題的一種思考方法，邏輯框架像金字塔結構，以上統下，歸納總結。
我理解中的結構化思維，是靈活可變的。比如上述提到的的 5W1H ，就是結構化思維的一種，因為這里體現的是一種結構，并非必須 5W+1H ，在合適場景也可以演變成 5W+2H 等。
當我們面對一個需求時，我們是如何進行分析的？出了方案應該如何和其他人描述？如何判斷方案的合理性？
一種人看了需求，了解需求概況，然后開始找參考找靈感，找到相同頁面類型的，然后看看有沒有什么可以借鑒（抄）的，開始發散思考表現和形式，提出的方案不清楚優劣性。這是不是像許多人平時思考需求、思考問題的方式？
而使用結構化思維的分析方式是：
一、仔細推敲需求產生的原因、背景，而不是單純只看需求，然后結合需求得出初步的改進目標。
二、分析需求的相關用戶群體。不同產品的相關用戶群體不一致，比如電商產品相關用戶群體是普通用戶、商家；網約車相相關用戶群體是用戶和司機；B 端產品相關用戶群體有客戶（負責購買）和用戶（負責使用）
三、結構化的分析競品，而不是單純找靈感。如看競品是如何做的，而看競品如何做并不是為了單純只看表象，也會從不同維度進行分析：競品為什么這么做，結果是什么？如果競品做得不如我們，他們的不足之處在哪里？競品這么做對我們有沒有參考意義？分析競品有助于我們通過別人的方案，幫助我們更清晰地分析目標的意義。圍繞目標，再發散思維，此時的方案會比第一種人更加緊密圍繞需求和目標，而不是單憑感覺去發散。我們提出的方案，相對而言也會更加具備理論、數據、分析的支撐。
四、分析方案的意義，方案對產品本身、對團隊等方面是否有更多的意義。舉個例子，你做的方案是否考慮到團隊其他成員的復用性？是否考慮到對當前業務的數據變化以及后續維護？更甚于，對自己的意義，是否能從中學習更多內在方法？
五、···
一個需求可以拆解成多個點進行解析。比如：產品問題+產品目標+產品定位+競品分析+相關用戶群體+體驗地圖+ ... + 需求類別特性（不唯一）。但是，并非每個需求都需要把產品定位、體驗地圖拿出來遛一遍，這樣子就變成了生搬硬套，我們需要根據具體需求思考不同的分析點。
我們在需求分析中，最常用到的是以下幾種，當然還有一些其他的拆分點，根據不同產品類型，分析的結構也不一致。
問題：我們產品當前遇到什么問題？
目標：針對當前的問題，我們期望達到什么目標？
競品分析：競品分析幾乎做需求前必做的，關鍵在于參考其他產品的設計思路，以及別人能夠做到什么樣的程度。基于目標，側重于從交互、UI 的設計層面進行分析、類比。
相關用戶群體：最基礎的當然是普通用戶，此外根據不同產品或者不同功能類型有：商家（電商類）、UP 主（B 站等）、CP（內容提供商）、司機（網約車類）等，甚至同一產品不同功能模塊需要考慮的相關用戶群體也不同。
需求類別特性：基于不同需求的相關內容而言的，這種變量會更聚焦于某需求的具體內容，但是一個具體需求是可以被拆分成多種維度，比如信息維度、框架維度、設計風格維度。假如你在做一個搜索的需求，分析的變量就是搜索操作類型、搜索推薦方式、搜索結果呈現規則等。假如你在做一個信息流的需求，分析的變量就是信息推薦規則、信息卡片呈現方式等。
結構性思維，無論是在溝通、處理分析問題上，對我們都有很大的幫助。在設計中，我們可以通過這種思考方式，避免讓方案過于發散而不聚焦，更好地判斷方案對于業務、團隊、自身的意義，以達到清楚方案的優劣性的目的。
1、本文介紹了設計師在項目中如何更好的溝通需求的方法，當然除了上述的方法之外，還有更多方法可以幫助我們解決問題，但我認為本質上是學會如何用全局的眼光看待需求，避免局限于具體解決方案。
2、在實際項目中，我們會遇到多種類型的需求，特別是遇到較大的需求時，運用合適的分析方法特別重要，這能夠很有指導性的幫助我們有意識、有節奏的看待需求。
3、避免為了使用某種方法論而強行使用，需要根據不同的需求場景使用不同的方法。
4、作為設計師，很關鍵的一點是判斷什么需求是真實需求、什么需求是偽需求，這在需求溝通、需求分析中會形成較大差異。當然這并非一朝一夕可以提升的，需要通過不斷學習對用戶行為及體驗的理解、對商業的理解才能提升。