hello 大家好，歡迎來到小島《UX基礎(chǔ)》專題的第一章。需求溝通是設(shè)計師日常工作對接的第一環(huán)，好的需求溝通過程能夠為設(shè)計過程進行提效，也能提前規(guī)避風(fēng)險與了解各方預(yù)期。接下來為大家介紹需求溝通過程前中后都可以用到的溝通與評估方法，以及過程中的注意事項。

一、需求的前置溝通

一些重大的項目設(shè)計師需要前置地介入到需求初期，在需求正式提過來之前就與各方探討需求的方向，這也是設(shè)計師價值的重要體現(xiàn)之一。在需求的前置溝通階段，我們可以準備以下幾件事情：

1. 提前介入需求，給出設(shè)計側(cè)建議：提前介入到需求中和各相關(guān)方開會，可以給出基于設(shè)計側(cè)的一些建議，在需求初期對體驗效果進行把控。除此之外，提前介入還可以大大減少收到需求后的信息差，因為我們從很早便已介入，主動傾聽和觀察各方溝通記錄。

2. 提前對該需求進行設(shè)計側(cè)的著手準備：重大項目設(shè)計側(cè)可以提前介入并完成前期的競品分析/用戶調(diào)研等過程，這樣正式收到需求后，就可以基于現(xiàn)有的調(diào)研直接進入到產(chǎn)出階段，更為高效。

3. 了解上級的期望：大型的需求初期我們要提前了解上級的期望、方向建議。切記不要"悶聲憋大招"！尤其是當任務(wù)是直接分配給我們的、過程中我們并沒有參會，要在開始前多詢問一下上級的目標和期待，時刻對焦對方的期待。

二、收到需求后，全面評估需求內(nèi)容

上游產(chǎn)品團隊在給設(shè)計側(cè)提需后（由于各公司均有自己提需格式/流程，以及對提需郵件的格式要求，這里不對此展開說明），在收到 prd 后，我們要全面仔細地查閱 prd，與產(chǎn)品進行線下溝通，大家可以在需求溝通的過程中明確以下內(nèi)容，在下述內(nèi)容都明確后再正式開始設(shè)計工作。

1. 了解需求背景

在了解需求背景時，大家需要搞清楚：

為什么發(fā)起這次需求？

為什么做這個需求？是什么觸發(fā)了本次的需求。是因為用戶數(shù)據(jù)下降？有不好的反饋？通過詢問上述情況，大致了解發(fā)起需求的原因。同時還要搞清楚需求的源頭，有時需求的源頭是業(yè)務(wù)側(cè)，產(chǎn)品側(cè)在其中進行了需求轉(zhuǎn)化，此時就要更深一步思考業(yè)務(wù)側(cè)為什么做這件事。

挖掘需求/問題的本質(zhì)

要思考需求或者問題的本質(zhì)，有些需求提過來時只是需求的表象，并不是真正的需求。

為了挖掘到問題的本質(zhì)，我們需要不斷地追問"why"，從一個初始問題不斷追問下去。

例如："為什么要做填寫頁提交強提示 alert？——因為用戶對其中一項投訴很多 ——為什么投訴很多 ——因為用戶不知道怎么填寫第五項就隨便進行選擇，最終導(dǎo)致所選內(nèi)容與實際訴求不符——為什么用戶不知道怎么填寫——填寫時的引導(dǎo)信息匱乏"。那么最終問題就被轉(zhuǎn)化成了表單設(shè)計項本身。

不斷追問 why，有助于我們找到最本質(zhì)的問題，找到了正確的問題，也就找到了那個相對正確的解決方案。一個正確的問題往往比無數(shù)個解決方案來的重要。

將抽象需求描述轉(zhuǎn)化成具像描述

有時我們收到需求時，對方的描述很抽象，此時就要不斷引導(dǎo)其將抽象轉(zhuǎn)化為具象。舉個例子，如果有人說 "我覺得展示的標簽數(shù)量有點少"。此時就要和對方明確"少"的定義是什么，多少算少？具體個數(shù)要求期望是多少？

再比如，對方說"我覺得整體頁面的線索有點亂。"，此時就要進一步明確他認為哪里亂，"亂"具體指的是什么。

對于可能會出現(xiàn)雙方理解偏差的問題，可以用自己的語言組織后再次確認"你的意思是指 xxxx 嗎？"；

我們要一步步挖掘?qū)Ψ綄λ谕繕说木呦蟊磉_，以幫助設(shè)計師明確優(yōu)化方向。

需求是在什么場景下、滿足哪部分用戶的什么目標和訴求？

1. 什么場景？：用戶需求通常是在特定場景下產(chǎn)生的，通過了解需求場景，能更好地帶入用戶角色中。場景不僅包括用戶所在環(huán)境，還包括了時間，我們能根據(jù)需求產(chǎn)生的時間分析持續(xù)時間和頻率，來判斷需求優(yōu)先程度。

2. 用戶是誰？：用戶的國家年齡、身份、性別等等

3. 要滿足用戶什么目標與訴求？：檢查需求是為了滿足用戶什么訴求，幫助用戶解決了什么問題/痛點，優(yōu)化改版后對他們而言有什么價值？此外還要從商業(yè)的角度，判斷這個需求如果做了，獲益的用戶是誰？如果不做，用戶是否會棄用，棄用用戶占比多大？

2. 需求的目標/價值

需求的目標主要分為以下幾個方面：

1. 商業(yè)目標：需求期望帶來多少收益，預(yù)判收入規(guī)模，和查看 ROI 計算結(jié)果，評判開發(fā)出來后是否真的會有用戶使用，用戶是否會為這個新產(chǎn)品/功能買單。審查商業(yè)目標有助于評估需求的優(yōu)先級進行排期。

2. 驗證指標：需求上線之后，將采用什么過程指標和結(jié)果指標（如交易平臺的 GMV 等），來驗證衡量項目是成功的。過程指標便于在結(jié)果指標出現(xiàn)異常時，作為歸因方法之一。

3. 短期和長期目標：避免需求只是短時間的縫縫補補，而沒有站在長遠的角度看待解決問題的策略，此時我們就要審視需求長期目標是什么，和從長遠的角度看待需求的必要性。

3. 需求的范圍

渠道范圍：包括 online、h5、app、后臺等等。

頁面范圍：涉及哪些應(yīng)用的哪些頁面。

4. 預(yù)期效果

了解需求的預(yù)期效果可以從以下方面入手：

1. 明確在產(chǎn)品團隊內(nèi)部知曉需求的基礎(chǔ)上，產(chǎn)品團隊期望達成的效果是什么樣子？對產(chǎn)出有什么具體的期望？是希望大改（且項目時間也允許）還是只是微調(diào)？

2. 明確自己 leader 期望達到的效果。

3. 明確團隊成員中每個人的期待，提煉總結(jié)團隊成員的想法。

5. 與需求"相關(guān)方"的溝通

1. 明確需求是否已經(jīng)和相關(guān)方溝通過：例如一個需求是另一個項目的配合需求，要明確這個需求是否和項目負責(zé)人同步過并獲得認可。又例如，一個需求涉及復(fù)雜的研發(fā)技術(shù)改造，就要明確是否已和開發(fā)溝通項目難度，以避免設(shè)計師一頓操作猛如虎最終發(fā)現(xiàn)無法實現(xiàn)，造成工作量浪費。如果項目對現(xiàn)狀改動很大，牽涉相關(guān)方很多，我們就需要和相關(guān)方確認這個頁面支持改動到什么程度。

2. 產(chǎn)品團隊內(nèi)部的溝通結(jié)果：明確需求是否是產(chǎn)品內(nèi)部討論的結(jié)果，明確執(zhí)行產(chǎn)品和其上級對需求的確定性。以避免未達成產(chǎn)品團隊期望。

3. 不盲目跟風(fēng)其他相似設(shè)計，及時了解背景：有時需求里會提到"希望和誰誰誰保持一致，和誰誰誰對齊"。對于這種需求，要先去了解下對方做這件事原因背景，再試想下基于對方的出發(fā)點是否適合于當前需求。不要盲目和別人對齊，要有自己的判斷。畢竟對于"他們也是這樣做的"這種理由是站不住腳的，并不是有別人在做，就代表這件事是"好的"和"適合我們的"。

6. 風(fēng)險預(yù)判

風(fēng)險預(yù)判是區(qū)分設(shè)計師能力的重要差異之一，優(yōu)秀的設(shè)計師能夠在短暫的溝通中預(yù)判需求的風(fēng)險，并給出恰當?shù)?、基于設(shè)計側(cè)的建議。切記再小的需求也不能缺失需求的風(fēng)險評估。

1. 可以套用線上數(shù)據(jù)進行模擬評估：套用現(xiàn)狀數(shù)據(jù)來評估風(fēng)險，這才會比較貼合業(yè)務(wù)的實際情況，避免主觀自我表達和毫無依據(jù)地說服別人。此外，當我們收集完現(xiàn)狀數(shù)據(jù)評估風(fēng)險后，上級和其他人才能夠依據(jù)你提供的信息作出決策。

2. 切換到用戶視角還原使用過程：對于產(chǎn)品方案，設(shè)計師要還原用戶的真實使用過程，試想實際使用過程中可能發(fā)生的問題，與團隊成員溝通解決掉這些問題。

7. 解決方案，和推導(dǎo)出解決方案的嚴謹度

除了要了解 prd 中所提出的解決方案，還要了解從需求到推導(dǎo)出解決方案的整個過程，是否合乎邏輯，推導(dǎo)是否足夠嚴謹：

嚴謹?shù)耐茖?dǎo)過程可以解釋——為何在無數(shù)種可能的解決方案中，最終選擇了這個解決方案？在雙鉆模型中往往需要發(fā)散解決方案和收攏解決方案來找到最合適的解法，因此對需求解決方案推導(dǎo)也是同理，在了解發(fā)散/收斂解決方案的思維過程中才能評判出，對比其他解決方案，當前解決方案是最合適的。

此外我們還要判斷解決方案是否可以真的解決問題，例如可以尋找線上數(shù)據(jù)進行模擬來驗證是否可以解決問題。

8. 功能清單與信息需求

功能清單：需求包括的功能有哪些？

功能對應(yīng)的流程圖：可視化的呈現(xiàn)一個功能的流程圖，例如新增一個商品需要經(jīng)過"信息填寫——提交校驗——新增成功"等步驟，每一個步驟可能會有成功和失敗狀態(tài)。

信息需求：詳細到每個功能對應(yīng)需要的每個字段。

產(chǎn)品整體流程圖：產(chǎn)品整體流程圖可以和上下游同事解釋在完成一個業(yè)務(wù)時，其中的場景、參與角色、彼此的關(guān)聯(lián)、核心的主流程。產(chǎn)品流程圖中要表明完成哪些任務(wù)、核心節(jié)點等。

9. 時間規(guī)劃

1. 需求上線時間計劃：包括評審、測試、驗收、發(fā)布上線時間節(jié)點等。

2. 如是較大項目需要拆分階段：按迭代周期將功能需求細分為多個開發(fā)階段，每個階段的上線時間分別是何時？檢查每個階段的目標完成時間和重要里程碑事件。

3. 明確實驗成功 or 失敗之后的規(guī)劃。

10. 調(diào)研資料

查看需求中是否附帶了前期的調(diào)研資料，包括：

用戶數(shù)據(jù)：例如人群特征、偏好、歷史使用數(shù)據(jù)等；

業(yè)務(wù)數(shù)據(jù)：商業(yè)數(shù)據(jù)，例如 xxx 優(yōu)惠券的覆蓋率等；

歷史文檔：歷史的相關(guān)項目文檔，例如 prd 和復(fù)盤等，站在別人的經(jīng)驗上才可以看得更遠。

11. 數(shù)據(jù)需求

埋點需求：查看埋點方案，如設(shè)計師需要增加一些驗證指標但缺少埋點，也可在埋點需求中新增埋點。

AB 實驗方案：AB 實驗的方案、周期。

12. 懂得拒絕與上升

當發(fā)現(xiàn)需求內(nèi)容不合理時，應(yīng)立刻聯(lián)系上級一起審核該需求，如團隊內(nèi)均認為需求不合理需要及時拒絕和提出意見給相關(guān)方。

三、對需求進行設(shè)計排期

在對需求進行排期時，需要注意以下內(nèi)容

1. 確定交付物形式/時間：和需求方確認，約定交付物的形式、最終的交付時間。如果需求較大要拆成幾期交付，明確什么時間要交付哪些具體內(nèi)容。

2. 在風(fēng)險解決后開始設(shè)計：在識別出的風(fēng)險都被解決的情況下，才可以正式開始設(shè)計，并且要將溝通過程中的風(fēng)險同步給上級和相關(guān)方。

3. 聚焦可行的設(shè)計方向：如果需求方案在溝通前可能朝著 10 個方向發(fā)散，我們要在需求溝通后從十個方向中選出一個/多個方向聚焦，再評估出對應(yīng)的排期，不要一股沿著 10 個方向發(fā)散。

4. 評判需求的優(yōu)先級：如果有多個需求，如何評判需求的優(yōu)先級呢？可以依據(jù)，該需求是否是今年核心策略和方向之一 ，依據(jù)投入產(chǎn)出比 ROI，以及需求的緊急程度。

四、后續(xù)與團隊內(nèi)部同步該需求

當我們后續(xù)在自己的團隊內(nèi)部同步這個需求時，要注意，盡管我們在需求調(diào)研階段溝通了大量的內(nèi)容，但我們并不需要把其中每個細節(jié)都事無巨細的同步到自己團隊，盡可能簡短的概述需求和自己做的重點事項。

1. 描述問題時，簡單直接："為了解決____場景的____用戶的____問題"。

2. 講清楚需求要達到的目標，我通過何種推導(dǎo)過程，收集了什么資料，依據(jù)哪些分析結(jié)論，推導(dǎo)產(chǎn)出了怎樣的方案，方案如何去達到這個目標。

3. 同步預(yù)判出來的風(fēng)險和風(fēng)險的解決結(jié)果。

以上就是需求溝通時可以考慮到的內(nèi)容，當然并不是所有的需求都需要包括以上內(nèi)容，可以根據(jù)需求的大小、需求的影響面酌情進行選取。愿大家都能擁有高效的需求溝通過程。

作者：飛向設(shè)計小島