關于需求

1、什么是需求：

這里的需求指業(yè)務需求，即現(xiàn)狀無法滿足需要，從而為達到某種目標而制定的。需求主體未必只有用戶，也可能是企業(yè)、產(chǎn)品、運營、技術。

2、需求的分類：

需求可以大致分類兩大類，內(nèi)部需求和外部需求。

什么是內(nèi)部需求？

內(nèi)部需求即由企業(yè)內(nèi)部發(fā)起的，基于企業(yè)、產(chǎn)品本身商業(yè)（產(chǎn)品、運營）、體驗（設計、技術）等層面的訴求而提出的。

產(chǎn)品的需求：由產(chǎn)品側發(fā)起，最為常見，通?；趯Ξa(chǎn)品發(fā)展目標、商業(yè)目標、競品動向、行業(yè)變化等層面考慮的需求。

運營的需求：由運營側發(fā)起，通?；谶\營活動、玩法等層面考慮的需求。

設計的需求：由設計側發(fā)起，通?；趯w驗、視覺等層面考慮的需求。

技術的需求：由技術側發(fā)起，通常基于對產(chǎn)品技術體驗、性能優(yōu)化等層面考慮的需求。

領導的需求：由公司上層發(fā)起，一般與產(chǎn)品經(jīng)理發(fā)起的需求類似，但有時也可能臨時想法。

···

什么是外部需求？

外部需求即所有在企業(yè)以外發(fā)起的，基于對企業(yè)產(chǎn)品的訴求、要求得不到滿足而提出的。

用戶需求：主要來自 C 端產(chǎn)品，用戶對于產(chǎn)品的反饋，或企業(yè)對用戶的調研而得出的需求。

客戶需求：主要來自 B 端產(chǎn)品，客戶對于產(chǎn)品功能、性能等層面考慮的需求。

政策需求：主要來自相關政策法規(guī)，通?；趯Ξa(chǎn)品合規(guī)性、用戶隱私權限等層面進行規(guī)范要求而整改的需求。

···

以上列舉的是常見的需求類型，可以發(fā)現(xiàn)需求類型其實是多樣的，設計師對于需求類型的鑒別也需要有一定的認知。

3、產(chǎn)品經(jīng)理與設計師的需求分析

在互聯(lián)網(wǎng)公司中，常見的職能角色主要有：產(chǎn)品經(jīng)理、交互設計（主要分布在中型、大型互聯(lián)網(wǎng)公司）、UI 設計、研發(fā)、測試。但除了產(chǎn)品經(jīng)理之外，設計師對于需求分析的了解也有很大的必要性。

上面提到，產(chǎn)品是需求的主要發(fā)起者，所以理所應當有很大一部分工作量就是需求分析。設計師的工作，最常見的就是對接需求，然后將需求轉化為設計。而這個流程中的關鍵點，就是作為交互、UI 設計師，應該如何正確的分析需求。

有人說，分析需求不是產(chǎn)品經(jīng)理的事情嗎？交互設計師只要會畫框架框架不就行了？如果這么想，那是還沒有對“分析需求”本身有足夠清晰的認知。

如果從用戶體驗五要素的層面對需求分析進行劃分，可以發(fā)現(xiàn)：

• 戰(zhàn)略層告訴我們“什么是產(chǎn)品目標、用戶需求”

• 范圍層告訴我們“什么方式、內(nèi)容、功能可以滿足需求”

• 結構層告訴我們“如何分布這些滿足需求的內(nèi)容、功能“

• 框架層告訴我們”如何設計這些滿足需求的界面框架、信息呈現(xiàn)”

• 表現(xiàn)層告訴我們“如何設計符合產(chǎn)品定位、風格、需求特征的最終展示外觀”

結論：

產(chǎn)品經(jīng)理的需求分析：側重于從商業(yè)維度考慮產(chǎn)品目標，考慮用戶的需求是什么，以及用什么樣的東西去滿足用戶需求。

設計師的需求分析：更側重于基于對產(chǎn)品需求的正確理解，從用戶、商業(yè)的層面考慮，并采用合適的設計形式來實現(xiàn)。

對齊需求：正確溝通

在體量較小的公司，產(chǎn)品經(jīng)理會肩負需求分析、交互設計等工作。而在體量較大或者更重視用戶體驗的公司，設計師則可以更加聚焦于如何權衡商業(yè)與用戶體驗。

這時，擺在產(chǎn)品經(jīng)理與設計師面前的會有 2 道鴻溝：

1、需求理解的鴻溝：

產(chǎn)品經(jīng)理是設計師最常見的需求對接者，基本上是產(chǎn)品經(jīng)理發(fā)起需求，設計師執(zhí)行。這個過程是先后關系，大部分情況下也是單向傳遞的。

當產(chǎn)品經(jīng)理比較強勢時，即使設計師對需求有疑問，也只能當成意見補充，而是否接受很大程度上是產(chǎn)品經(jīng)理決定。這里面的溝通很關鍵，因為這條鴻溝決定著設計師是否能夠正確理解需求背后的本質，理解本質需求就是跨越這條鴻溝的橋梁。

正確的溝通姿勢是理解需求的第一步，而這一步基本定義了整個交互、UI 的設計走向，需求目標會影響設計師的思考方式，當沒有將需求目標透徹理解時，會使思考方式嚴重受限，比如產(chǎn)品需求是讓設計一個彈窗，設計師就原原本本的設計一個彈窗，而不去思考為什么要設計這個彈窗。

我們該如何正確理解需求？

關注本質

產(chǎn)品輸出需求文檔的時候，大多會輸出初步的交互框架想法或者視覺設計建議，但在需求溝通時，最關鍵的一點是關注本質需求，避免一開始就陷進具體的需求細節(jié)。這里并非說產(chǎn)品提供的方案不好，事實上，有時交互方案與產(chǎn)品提供的方案一致，這是不可避免的，當目標相對清晰的時候，不需要為了特地設計而設計。

但是，如果溝通需求時，過于關注細節(jié)，容易導致看不清需求的本質。所以，當與產(chǎn)品經(jīng)理溝通時，可以多問問為什么要做這個需求，是為了達到什么目標，滿足什么需求，然后從交互體驗、創(chuàng)意性等角度出發(fā)，思考更好的交互方案。

甄別需求

無論是內(nèi)部需求還是外部需求，一般都會匯總到產(chǎn)品經(jīng)理，再由產(chǎn)品經(jīng)理與設計側以及其他職能同事對接。需求來源多樣，特別是用戶需求，我們都知道用戶表達或反饋的需求未必是用戶的真實需求，所以在溝通時，應該甄別哪些需求不合理。設計師有用戶體驗的立場，站在不同立場上，往往可以發(fā)現(xiàn)不同的問題，將問題在需求階段暴露出來，避免執(zhí)行過程反復調整。

2、意見沖突的鴻溝：

產(chǎn)品經(jīng)理與設計師職能不同，所以立場、關注點都會有差別。

首先，我們需要接受產(chǎn)品經(jīng)理與設計師的意見是一定會產(chǎn)生沖突的，所以不要覺得為什么與產(chǎn)品經(jīng)理怎么總是意見不合。

其次，站在雙方的共同目標都是讓產(chǎn)品變得更好的角度，我并不認為意見沖突是不好的，相反，這是在前期基于雙方不同立場對于需求本身合理性的充分討論，達到雙方都認同的意見，然后共同將產(chǎn)品做好。

如何跨過產(chǎn)品經(jīng)理與設計師意見沖突的鴻溝？

理解目標

要看清這個問題，需要回歸到產(chǎn)品經(jīng)理與設計師立場的差異上，設計師習慣性的會站在用戶體驗的角度上思考問題，也往往需要為體驗負責，而產(chǎn)品經(jīng)理需要考慮更多產(chǎn)品策略方面的問題，有業(yè)務的 KPI。

在溝通需求時，雙方意見不合主要是關注的目標不一致。這時，設計師不該只從體驗好與不好、這么做好不好看的角度出發(fā)思考問題，而是需要基于用戶體驗并在理解商業(yè)目標的基礎上進行溝通。作為設計師，不能盲目接受需求，更不能盲目拒絕需求。

提前介入

不同企業(yè)的產(chǎn)品流程會有一些差異，但大部分是產(chǎn)品需求過了幾輪評審之后，流轉到設計。此時就算設計師對需求有不同意見且產(chǎn)品也同意調整，在某些情況下也可能造成項目延期的風險。

如果條件允許，設計師可以提前介入到需求評審階段，即在需求評審初期可以表達設計側對需求的看法，而需求評審可以充分進行需求討論。此外，某些產(chǎn)品需求（比如要求較多的設計創(chuàng)意發(fā)散）可能會強依賴于設計、動畫等職能角色參與，提前介入可以在需求前期有充分表達設計觀點的機會。

拆解需求：5W1H 法

5W1H 分析法也叫六何分析法，是一種思考方法，也是工作方法。可以幫助我們避免只關注某個細節(jié)或者具體的需求方案，而是從頂層開始思考的方式。

大部分人都聽過這個方法，但是日常工作中不太知道應該如何使用，個人理解，這個方法在很小的需求方面不太適合。但是在處理比較中型/大型的需求、設計師對需求本身疑惑時、甚至與產(chǎn)品經(jīng)理意見分歧時，有很大的用處。

原因（ Why）：

需求的背景是什么，產(chǎn)品在當前遇到了什么問題，比如數(shù)據(jù)差、體驗反饋差等。

想要達到什么目標，是商業(yè)需求還是用戶需求？

產(chǎn)品所在行業(yè)的競品情況如何，市場趨勢如何？

對象（ What）：

需求的內(nèi)容是什么，基于需求的背景、目標，產(chǎn)品即將做什么事情？注意不能局限于做某個具體形態(tài)的事情，可以嘗試描述這件事情如何滿足需求。

場景（ Where）：

什么場景出現(xiàn)這個需求？

需求的最終產(chǎn)物會在什么場景/頁面/模塊出現(xiàn)？

時間（When）：

什么時間節(jié)點出現(xiàn)這個需求？

需求的最終產(chǎn)物會在什么時間節(jié)點出現(xiàn)？

用戶（Who）：

產(chǎn)品的用戶是誰？這個“誰”不是只某個個體，而是產(chǎn)品的某類典型群體。

用戶需求是什么？用戶遇到了什問題？可以將用戶需求枚舉出來，但是需要注意用戶需求不一定等于產(chǎn)品需求。

方法（How）：

需求所要做的這件事情，實現(xiàn)方式是怎么樣的？

有沒有其他可能的方式可以更好的實現(xiàn)這件事情？

思考產(chǎn)品提出的需求建議方案，與需求目標是否一致。設計師理解并同意以上拆分的結論，那就證明需求本身層面是沒有異議的，接下來就是需求實現(xiàn)層面的問題了，此時設計師的工作，就是思考是否還存在更好的實現(xiàn)方式能夠滿足這個需求。如果以上問題不夠明確，那么可能需求本身可能有值得商榷的部分。

以需求目標為導向，是判斷方案是否可行的最直接方法。這種溝通方式，可以幫助設計師與產(chǎn)品經(jīng)理構建相同目標、場景等變量信息，幫助產(chǎn)品經(jīng)理與設計師對齊設計目標，減少后續(xù)方案返工的情況。我們通過梳理這些信息，盡管未必能夠馬上思考出方案，但是能夠初步判斷哪些方案可能不太合適。

以上是對于 5W1H 的基本拆解，下面我會嘗試舉一個虛擬例子進行解釋。

某天，產(chǎn)品經(jīng)理提了一個需求：

需求內(nèi)容：

優(yōu)化用戶取消訂單的挽留彈窗。線上的樣式是底部彈窗，但是底部彈窗容易點擊“取消訂單”按鈕，且文字提示不夠清晰。初步方案是將彈窗樣式改成居中彈窗，對于用戶提醒層面會更加明顯，如下圖：

你覺得很奇怪，把彈窗從底部改為居中樣式，盡管提示更明顯了，但是真的能夠降低用戶的取消率嗎？實際上，你甚至不清楚這個彈窗對于用戶是否有幫助，也不清楚是否能解決需求的問題。你可能會思考，假如你是用戶，會因為這個彈窗就不取消訂單嗎？

很多產(chǎn)品都會設計頁面退出時的挽留彈窗，常見的如“確定退出頁面嗎？ 退出/取消”，但這經(jīng)常是一種為了做而做的挽留彈窗。對于這種彈窗，是否可能不僅不能帶來目標效果，反而容易引起用戶的反感。

我們在分析需求時，可以嘗試簡單拆解一下這個需求：

原因（Why）：

需求的背景：行業(yè)內(nèi)，用戶下單之后都有取消訂單的操作，本平臺的訂單取消率處于行業(yè)中的平均水平，基于對產(chǎn)品的優(yōu)化，希望可以降低訂單的取消率。

對象（What）：

通過某種方式，降低訂單取消率。目前比較合適的方式是優(yōu)化取消訂單的挽留彈窗。

場景（Where）：

我的訂單頁，目前其他場景無法取消訂單，所以場景比較明確。

時間（When）：

用戶已經(jīng)下單（已支付/未支付）之后，點擊【取消訂單】按鈕后觸發(fā)挽留彈窗。

用戶（Who）：

目標用戶：已經(jīng)下單的用戶。

用戶需求：枚舉用戶遇到的問題，如：點錯了、忘記支付密碼、不想買了、收貨地址填錯了、其他原因…

方法（How）：

初步想法：把底部挽留彈窗改成居中挽留彈窗。

其他想法：是否還有其他方式降低取消率？

你會發(fā)現(xiàn)，這個需求其實是可以被拆解的。在這個需求里，你會發(fā)現(xiàn)，盡管原因（Why）很清晰，但是用戶（Who）是推導出來的結論方法（How）是有些問題的。當從用戶角度出發(fā) ，僅僅一個居中挽留彈窗是無法解決用戶需求的。

這里需要警惕一個點，即設計“挽留彈窗”這件事情，先不管最終產(chǎn)物是不是一個彈窗的形式，但是不能一開始就陷入“我要設計一個彈窗”的思維，可以先思考下，我需要通過什么方式降低用戶的取消率？

但是我們?nèi)绾伟l(fā)現(xiàn)潛在的更優(yōu)方案呢？

可以嘗試多幾個問號：用戶為什么會取消訂單？設計挽留彈窗，是否就真的對降低取消率？設計挽留彈窗，能否解決用戶在這個場景遇到的問題？是否可能不用挽留彈窗降低取消率？

通過上面用戶需求列舉，你可能會發(fā)現(xiàn)部分取消訂單原因，是不需要用戶取消了訂單才能解決的，比如“地址填錯了”，并且這部分用戶在本平臺訂單取消率中占了一大部分。

這時需求的解決方式，可能變成：

· 通過向用戶提供修改收貨地址的入口降低訂單取消率。此時彈窗的動機不再是為了“阻擋”用戶，而是推測用戶操作意圖，幫助用戶解決問題。相比于單純的阻擋彈窗，這種處理方式的好處是：通過找到并解決部分操作的根本原因，以減少負向操作，幫助平臺更好分析用戶取消訂單的原因以改善產(chǎn)品體驗；

· 如果填錯地址的用戶占了訂單取消率的很高比重，是否可能嘗試優(yōu)化下單流程？比如將讓用戶更明確感知訂單地址，避免用戶選錯地址。從而通過優(yōu)化本質的問題，減少用戶取消訂單的比例，也減少彈窗出現(xiàn)的頻次。

最后你會發(fā)現(xiàn)，設計出來的方案可能會以彈窗作為表現(xiàn)形式，也可能通過優(yōu)化下單流程降低取消率。這個方法主要是將需求梳理清楚，讓我們明確這個需求的來龍去脈，減少遺漏的問題。

發(fā)現(xiàn)真正需求：雙鉆設計模式

2005年，英國設計協(xié)會（the British Design Council）首次提出這種雙發(fā)散—聚焦設計模式，被稱作雙鉆設計模式（double-diamond design process model）。英國設計協(xié)會將設計過程分為四個步驟：“發(fā)現(xiàn)”和“定義”，確認正確問題的發(fā)散和聚焦階段；然后是“構思”和“交付”，制定正確方案的發(fā)散和聚焦階段?！?

迄今為止，我們其實可以看到許多設計方法，這些方法可以讓我們避免從初始問題直接思考解決方案，避免因為忽視真正的、根本的問題而設計價值不大的設計方案。雙鉆設計模式，與上面的 5W1H 分析法都是屬于設計分析方法，也同樣可以幫助我們?nèi)绾畏治鲂枨?、拆解需求、解決正確的問題。

設計師在需求分析過程中，要明確需求是某種方案，但未必是最終結果。盡管從效率層面看起來像是在倒退，因為明明產(chǎn)品經(jīng)理已經(jīng)提供了方案，而設計師還要重新思考。但實際上，這種思考方式，恰恰可以避免局限于某種職能視角思考問題。

為什么稱為雙鉆模型？

1、設計師會先質疑問題，接著擴大問題的范圍，思考問題之下隱藏的根本原因，接著聚焦于其中某一個問題的描述。

2、在思考解決方案階段，會先擴展可能的方案，再進行一次發(fā)散思考。最后，將這一切重歸于某個合適的方案。

拿到問題——發(fā)散——聚焦——發(fā)散——聚焦，看起來像是兩顆并列的鉆石，所以稱作雙鉆模型。

發(fā)現(xiàn)問題

對現(xiàn)狀進行深入研究。包括了解用戶特征、產(chǎn)品當前狀況、用戶如何使用產(chǎn)品以及用戶對產(chǎn)品的態(tài)度、競品現(xiàn)狀等，此時我們不會將聚焦于某一個問題，而是窮舉盡可能多的潛在問題。

定義問題

確定關鍵問題。這一階段，我們關注的焦點是：用戶當前最關注、最需要解決的問題是哪些，需要根據(jù)團隊的資源狀況作出取舍，聚焦到核心問題上。

構思方案

尋找潛在的解決方案。在方案發(fā)散階段，我們不需要過多考慮技術的可實現(xiàn)性。

交付方案

把上階段所有潛在的解決方案，逐個進行分析驗證，選擇出最適合的一個或多個方案。 我認為在這個階段，設計師可以盡可能地發(fā)散想法，但是就絕大多數(shù)國內(nèi)企業(yè)、產(chǎn)品現(xiàn)狀而言，很難將多種想法一一嘗試，因為開發(fā)成本、項目時間等問題，可能導致投入產(chǎn)出比不高的情況，所以設計師應該提升對好方案的判斷能力。

我們該如何使用雙鉆設計模式，同樣在此我會舉一個虛擬例子進行解釋。

你們是內(nèi)容資訊類產(chǎn)品，某天，你接到一個需求：

需求內(nèi)容：

優(yōu)化某應用 App 首頁搜索欄，包括將搜索欄高度加高、設計顏色更加明顯，以提升搜索欄的點擊率。

需求背景：

對比了同行業(yè)競品，發(fā)現(xiàn)競品的搜索欄點擊率比我們高了20%。我們的搜索欄點擊率為 5%，而競品為 20%。同時，通過對比發(fā)現(xiàn)，競品搜索欄高度更高，搜索欄顏色更加明顯，除此之外，頁面其他信息區(qū)別不大。

初步分析：

這個需求問題很明確，就是我們搜索欄點擊率比競品低。但這個問題歸因真的全因搜索欄高度、設計樣式的影響嗎？

其實未必是這個原因，搜索欄的點擊行為本身更傾向于目的性點擊，也就是說有相對明確的目的去點擊，而目前高度雖然不高，但是足夠明確。

采用雙鉆設計模型分析：

通過雙鉆模型“發(fā)散——聚焦”的分析和驗證，我們發(fā)現(xiàn)最終解決方案不僅僅是最初的方案，這四個階段不是孤立存在的，而是彼此聯(lián)系。當然這種舉例是為了更加便于理解，實際項目中一定會遇到很多問題是很復雜且很難順利解決的。但是這種設計模式幫助我們減少用局限性的眼光進行設計，發(fā)現(xiàn)正確的問題，發(fā)現(xiàn)正確的解決方案。

分析思維：結構化思維

首先，什么是結構性思維？

有人這么解釋：以事物的結構為思考對象，來引導思維、表達和解決問題的一種思考方法，邏輯框架像金字塔結構，以上統(tǒng)下，歸納總結。

我理解中的結構化思維，是靈活可變的。比如上述提到的的 5W1H ，就是結構化思維的一種，因為這里體現(xiàn)的是一種結構，并非必須 5W+1H ，在合適場景也可以演變成 5W+2H 等。

當我們面對一個需求時，我們是如何進行分析的？出了方案應該如何和其他人描述？如何判斷方案的合理性？

一種人看了需求，了解需求概況，然后開始找參考找靈感，找到相同頁面類型的，然后看看有沒有什么可以借鑒（抄）的，開始發(fā)散思考表現(xiàn)和形式，提出的方案不清楚優(yōu)劣性。這是不是像許多人平時思考需求、思考問題的方式？

而使用結構化思維的分析方式是：

一、仔細推敲需求產(chǎn)生的原因、背景，而不是單純只看需求，然后結合需求得出初步的改進目標。

二、分析需求的相關用戶群體。不同產(chǎn)品的相關用戶群體不一致，比如電商產(chǎn)品相關用戶群體是普通用戶、商家；網(wǎng)約車相相關用戶群體是用戶和司機；B 端產(chǎn)品相關用戶群體有客戶（負責購買）和用戶（負責使用）

三、結構化的分析競品，而不是單純找靈感。如看競品是如何做的，而看競品如何做并不是為了單純只看表象，也會從不同維度進行分析：競品為什么這么做，結果是什么？如果競品做得不如我們，他們的不足之處在哪里？競品這么做對我們有沒有參考意義？分析競品有助于我們通過別人的方案，幫助我們更清晰地分析目標的意義。圍繞目標，再發(fā)散思維，此時的方案會比第一種人更加緊密圍繞需求和目標，而不是單憑感覺去發(fā)散。我們提出的方案，相對而言也會更加具備理論、數(shù)據(jù)、分析的支撐。

四、分析方案的意義，方案對產(chǎn)品本身、對團隊等方面是否有更多的意義。舉個例子，你做的方案是否考慮到團隊其他成員的復用性？是否考慮到對當前業(yè)務的數(shù)據(jù)變化以及后續(xù)維護？更甚于，對自己的意義，是否能從中學習更多內(nèi)在方法？

五、···

一個需求可以拆解成多個點進行解析。比如：產(chǎn)品問題+產(chǎn)品目標+產(chǎn)品定位+競品分析+相關用戶群體+體驗地圖+ ... + 需求類別特性（不唯一）。但是，并非每個需求都需要把產(chǎn)品定位、體驗地圖拿出來遛一遍，這樣子就變成了生搬硬套，我們需要根據(jù)具體需求思考不同的分析點。

我們在需求分析中，最常用到的是以下幾種，當然還有一些其他的拆分點，根據(jù)不同產(chǎn)品類型，分析的結構也不一致。

問題：我們產(chǎn)品當前遇到什么問題？

目標：針對當前的問題，我們期望達到什么目標？

競品分析：競品分析幾乎做需求前必做的，關鍵在于參考其他產(chǎn)品的設計思路，以及別人能夠做到什么樣的程度?；谀繕耍瑐戎赜趶慕换?、UI 的設計層面進行分析、類比。

相關用戶群體：最基礎的當然是普通用戶，此外根據(jù)不同產(chǎn)品或者不同功能類型有：商家（電商類）、UP 主（B 站等）、CP（內(nèi)容提供商）、司機（網(wǎng)約車類）等，甚至同一產(chǎn)品不同功能模塊需要考慮的相關用戶群體也不同。

需求類別特性：基于不同需求的相關內(nèi)容而言的，這種變量會更聚焦于某需求的具體內(nèi)容，但是一個具體需求是可以被拆分成多種維度，比如信息維度、框架維度、設計風格維度。假如你在做一個搜索的需求，分析的變量就是搜索操作類型、搜索推薦方式、搜索結果呈現(xiàn)規(guī)則等。假如你在做一個信息流的需求，分析的變量就是信息推薦規(guī)則、信息卡片呈現(xiàn)方式等。

結構性思維，無論是在溝通、處理分析問題上，對我們都有很大的幫助。在設計中，我們可以通過這種思考方式，避免讓方案過于發(fā)散而不聚焦，更好地判斷方案對于業(yè)務、團隊、自身的意義，以達到清楚方案的優(yōu)劣性的目的。

結語

1、本文介紹了設計師在項目中如何更好的溝通需求的方法，當然除了上述的方法之外，還有更多方法可以幫助我們解決問題，但我認為本質上是學會如何用全局的眼光看待需求，避免局限于具體解決方案。

2、在實際項目中，我們會遇到多種類型的需求，特別是遇到較大的需求時，運用合適的分析方法特別重要，這能夠很有指導性的幫助我們有意識、有節(jié)奏的看待需求。

3、避免為了使用某種方法論而強行使用，需要根據(jù)不同的需求場景使用不同的方法。

4、作為設計師，很關鍵的一點是判斷什么需求是真實需求、什么需求是偽需求，這在需求溝通、需求分析中會形成較大差異。當然這并非一朝一夕可以提升的，需要通過不斷學習對用戶行為及體驗的理解、對商業(yè)的理解才能提升。