我們聽多了關(guān)于why和what的balabala，最后發(fā)現(xiàn)要么落不了地，要么最終效果和想要的完全不是一個東西。所以，本文作者想和你聊聊關(guān)于需求落地的那些事兒……

產(chǎn)品設(shè)計3步曲-“2W1H”

任何一個偉大的產(chǎn)品的誕生都會經(jīng)歷這3步曲：

1. 把冰箱門打開；
2. 把大象裝冰箱里；
3. 把冰箱門關(guān)上。

具體到產(chǎn)品設(shè)計過程，這3步曲分別可以定義為：

1. 問題定義（簡稱“Why”）；
2. 問題求解（簡稱“What”）；
3. 思路拆解（簡稱“How”），簡稱“2W1H”。

1. Why

為什么要做…

解決了怎樣的問題

2. What

通過“X”來解決

3. How

怎樣拆解“X”？

我們聽多了關(guān)于Why和What的balabala，最后發(fā)現(xiàn)要么落不了地，要么最終效果和想要的完全不是一個東西。所以這次想和你聊聊關(guān)于需求落地的那些事。

“Why”和“What”主要側(cè)重戰(zhàn)略層面的思考，如何發(fā)現(xiàn)并定義問題，并能夠給出創(chuàng)造性的解決方案；“How”主要側(cè)重落地層面的推演，通過邏輯層面的枚舉、關(guān)聯(lián)以及權(quán)衡，梳理出解決方案可能涉及的每一個脈絡(luò)，并以文檔的形式進行產(chǎn)出，為開發(fā)、設(shè)計提供行動指南。

關(guān)于需求落地

第一步：拆解“X”的主要流程

梳理用戶完成“X”事件過程中的主要流程。以注冊過程中的“手機號驗證”事件為例，其所涉及到主要流程如下：

1. 國際化中首先需要判斷眾多手機號位數(shù)是否符合當前Country Code規(guī)則，以確保當驗證碼失敗時不是因為手機號碼位數(shù)造成的。
2. 涉及到用戶個人身份的賬號體系需要有搶手機好功能，即注冊過程中當檢測到手機號碼被注冊時，需要詢問用戶當前存在賬號是否為自己，如果不是則重新生成賬號，如果是則去登錄頁。
3. 為了防止用戶惡意利用驗證碼請求，還需要有驗證碼防轟炸機制。

通過流程分析，可以拆解出實現(xiàn)X的重要步驟是什么，接下來，需要逐一確認這些步驟中的細節(jié)。

第二步：確定細節(jié)

1、確認主要流程中業(yè)務(wù)邏輯細節(jié)

（1）提升體驗

有助于提升產(chǎn)品體驗的規(guī)則，如在手機號輸入過程中為了減少因為手機號碼位數(shù)錯誤而造成無法收到驗證碼的情況發(fā)生，前端在檢測到用戶輸入字符數(shù)量符合當前國家碼對應(yīng)位數(shù)時，所輸入的手機號碼會按照指定格式炸開。

（2）商業(yè)增值

有助于完善產(chǎn)品商業(yè)模式，如相比與普通用戶，Momo會員可以享受33項個性化特權(quán)。

（3）受資源/成本的限制或快速迭代帶來的壓力

有些策略雖然可以完美地解決當下遇到的問題，但受限于客觀資源或較短迭代的周期不得不做妥協(xié)。那么怎樣去做妥協(xié)？以及妥協(xié)到什么程度呢？

首先你需要非常明確要做的這個點對于產(chǎn)品的價值貢獻程度或優(yōu)先級一定是較高的，即意味著這個點在這個迭代必須要上。這時你需要再深入挖掘開發(fā)的難點到底在那個環(huán)節(jié)，為什么困難，在不影響功能實現(xiàn)的前提下，體驗的哪些妥協(xié)可以大幅降低開發(fā)成本，并在規(guī)定期限或資源限制內(nèi)交付。

2、確定主要流程界面的10種狀態(tài)樣式細節(jié)

（1）初始狀態(tài)

頁面、組件以及控件的初始狀態(tài)是怎樣子？是否需要提供默認值幫助用戶快速的“點點點”。

（2）等待

只要涉及到數(shù)據(jù)的提交、上傳，就需要用戶等待。靜止的事物會讓覺得自己行為沒有得到響應(yīng)，通過動畫傳遞當前系統(tǒng)正在響應(yīng)自己的行為。

（3）輸入

通過怎樣的方式向系統(tǒng)傳達指令？

移動端常見的輸入方式有：輸入框、人體模型、標簽、第三方信息授權(quán)、滑塊、滾動框、開關(guān)、篩選器、隨機、提交、返回、前進、手勢、退出、語音、圖像、視頻、指紋等。

結(jié)合數(shù)據(jù)類型，選擇合適的輸入方式。

需要輸入姓名、賬號之類的高自由度的數(shù)據(jù)，可以選擇輸入框或者第三方信息授權(quán)輸入方式；

需要輸入密碼之類的隱私性數(shù)據(jù)，可以選擇輸入框、手勢譜、語音、圖像、視頻、指紋等；

需要輸入“0-1”數(shù)據(jù)可以考慮開關(guān)；需要輸入特定緯度下的數(shù)值信息可以考慮滑塊、滾動框；需要輸入泛緯度數(shù)據(jù)可以考慮標簽、篩選器；

需要輸入“l(fā)ucky”信息可以考慮隨機個性化輸入方式

（4）空態(tài)

只要是涉及到數(shù)據(jù)呈現(xiàn)的界面，都極有可能存在空態(tài)頁，提前準備好空態(tài)頁，避免開發(fā)再問你要或擅作空態(tài)處理，顯得自己很不專業(yè)。

（5）有數(shù)據(jù)

如何呈現(xiàn)已有數(shù)據(jù)？

移動端常見的數(shù)據(jù)呈現(xiàn)方式有：列表、陣列網(wǎng)格、卡片、泳道、瀑布流（單/多）、抽屜、折疊、數(shù)據(jù)可視化、3D球列表等。

（6）過多數(shù)據(jù)

數(shù)據(jù)太多，怎么顯示？

常用的數(shù)據(jù)壓縮方法有：超過省略、折疊、二級頁展示、滾動選項卡、設(shè)定極限、設(shè)定頭尾等。

（7）用戶行為數(shù)據(jù)的提交

涉及到用戶行為數(shù)據(jù)的提交，需要有結(jié)果反饋。

（8）表單

涉及到連續(xù)任務(wù)時，最好用表單結(jié)構(gòu)。

（9）事件結(jié)束

事件的結(jié)束不等于行為閉環(huán)了，深入用戶使用場景，揣摩用戶可能還想干嘛？最終能夠閉環(huán)每個事件。

（10）無網(wǎng)絡(luò)

無網(wǎng)絡(luò)是最常見的異常狀態(tài)，精心設(shè)計的無網(wǎng)絡(luò)狀態(tài)會緩解用戶的沮喪，至少不會將這一切歸咎于自生的錯。

3、綜合所有的脈絡(luò)信息最終確定最合理的脈絡(luò)細節(jié)

脈絡(luò)細節(jié)的確定是需求落地過程中最復雜、最困難的環(huán)節(jié)，任何一個你看得到的細節(jié)變動可能還連帶著其他不容易發(fā)現(xiàn)的脈絡(luò)點。具體到細節(jié)確定，不是簡單地解決當下所拋出的表象問題，而是需要綜合所有潛在的脈絡(luò)信息，確保解決當下問題的同時，還不會影響原先正常細節(jié)的可用性。

今年10月份，我們做了一個關(guān)于熟人匿名投票的項目，其中有一部分是關(guān)于好友體系的設(shè)計。業(yè)務(wù)層面，我們希望用戶快速添加好友，完成投票行為，因此我們設(shè)計了門檻最低的單向好友體系，即用戶無需對方同意，可以直接添加好友，具體到好友頁面還有3個需要確定的需求細節(jié)。

• 最上方的泳道卡片被添加后是否需要消失？
• 消失后還需要再出現(xiàn)嗎？如果再出現(xiàn)，時機又是什么？
• 既然是單向好友體系，那么還需要好友申請頁嗎？如果需要，申請頁中的用戶狀態(tài)分別有哪些？

（1）最上方的泳道卡片被添加后是否需要消失？

第1個細節(jié)比較容易確定，因為脈絡(luò)點很明顯且唯一，即我們希望更方便用戶添加泳道里的不同好友，因此好友卡片被添加后需要消失。

（2）消失后還需要再出現(xiàn)嗎？如果再出現(xiàn)，時機又是什么？

如果不出現(xiàn)，就意味著我很快就會把通訊錄好友都點完，之后推薦泳道就空了；但如果出現(xiàn)，就意味著我可以重復點一個好友多次。我們發(fā)現(xiàn)這兩個假設(shè)其實互為正負關(guān)系，因此只需權(quán)衡兩端的優(yōu)劣，就可以確定該關(guān)系下的脈絡(luò)細節(jié)。

① 重復添加好友–脈絡(luò)信息分析

推薦泳道包含APP和通訊錄未注冊兩類好友，由于是單項好友關(guān)系，因此對于APP好友來說，幾乎是沒有任何影響的；對于通訊錄未注冊好友來說，會涉及到短信通知，如果出現(xiàn)濫用重復添加的情況時，只需要在短信規(guī)則上做限制就可以規(guī)避，此外如果短信規(guī)則制定合理，還助于初期我們在種子用戶傳播維度的提升。

② 次性把通訊錄都點完–脈絡(luò)信息分析

對比重復添加好友，一次性將通訊都點完，太過被動，不符合當前階段的產(chǎn)品目標。

綜上，我們將通訊錄更新交由前端來實現(xiàn)，即用戶點擊添加Button后，該用戶消失，但每次重新打開APP又會重新上傳本地通訊錄，后臺會判斷上傳的通訊錄中有哪些已經(jīng)是好友關(guān)系，如果不是則再次出現(xiàn)。

（3）既然是單向好友體系，那么還需要好友申請頁嗎？如果需要，申請頁中的用戶狀態(tài)分別有哪些？

① 脈絡(luò)細節(jié)-需要驗證頁

雖然是單向好友關(guān)系，無需對方同意就可以添加對方為好友，但好友行為的本質(zhì)還是一個雙向token，只是相對于標準好友體系，單向好友關(guān)系降低了加好友的門檻，因此我們還需要將這一事件告知對方，即需要驗證頁。

用戶A添加用戶B，用戶B將會在新的好友頁收到一個假申請請求，用戶B點擊“同意”Button不是通過A的好友驗證，而是執(zhí)行加A為好友的操作。

那么問題來了，用戶B點擊“同意”Button后，好友A會消失嗎？如果不消失，此時的“同意”Button應(yīng)該切換成什么狀態(tài)？

② 脈絡(luò)細節(jié)-新的好友頁

假設(shè)消失，如果此時B刪除了A，B再去添加A，A的新的好友頁更新B的好友申請，此時A出現(xiàn)了重復添加了B的操作，即消失細節(jié)不可行；那假設(shè)不消失，新的好友頁有該是怎樣的細節(jié)呢？

我們發(fā)現(xiàn)這時好友模式與關(guān)注體系非常相似，于是我們將“我的好友”類比成“我的關(guān)注”，“新的好友頁”類比成“我的粉絲”。對于用戶A的“新的好友頁”來說，“用戶B 同意”代表用戶B關(guān)注了A，但是A還沒有關(guān)注B；“用戶B 已添加”代表用戶AB相互關(guān)注。

再回到我們之前假設(shè)的場景：B刪除了A意味著B不再是A的粉絲，所以這時A的“新的好友頁”不再有B，但此時B依然是A的好友，即A還在關(guān)注B，這時B又添加A，即B又重新關(guān)注了A，這時AB關(guān)系是互為關(guān)注，依據(jù)之前的類比，AB互為關(guān)注應(yīng)該顯示“用戶B 已添加”，即這時在B的“我的好友頁”顯示“用戶B 已添加”。

小結(jié)

落地永遠比想法更重要，置于如何落地，首先你得對問題的解決策略做到心中有數(shù)，能夠梳理出其中關(guān)鍵的業(yè)務(wù)流程，之后再去聚焦每個流程中的細節(jié)。

在細節(jié)確定方面，你需要對業(yè)務(wù)本身有充分的了解，能夠依據(jù)“提升體驗”、“商業(yè)增值”目標抑或來自資源/成本的限制等維度快速確定好業(yè)務(wù)細節(jié)；其次在具體的頁面維度，能夠本能地識別出頁面模塊類型，并能給出相應(yīng)交互設(shè)計策略；最后是最難也是最普遍的，在面對新細節(jié)時，不要理所應(yīng)當?shù)卣J為只要確定當下細節(jié)就可以了，現(xiàn)實情況下大部分細節(jié)都不是單獨存在的，往往還連帶著其他你可能看不到的細節(jié)，這時你需要有一個全局視角，更加綜合地看待當下要解決的問題細節(jié)，不要出現(xiàn)拆了東墻又去補西墻的尷尬。

#專欄作家#

UE小牛犢，微信公共號：UE小牛犢，人人都是產(chǎn)品經(jīng)理專欄作家。關(guān)注產(chǎn)品思考、用戶體驗分析、交互研究，致力于UX方法論的探索和實踐。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Pexels，基于 CC0 協(xié)議