產品設計3步曲:如何讓需求穩穩地落地

2 評論 17251 瀏覽 241 收藏 17 分鐘

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

產品設計3步曲-“2W1H”

任何一個偉大的產品的誕生都會經歷這3步曲:

  1. 把冰箱門打開;
  2. 把大象裝冰箱里;
  3. 把冰箱門關上。

具體到產品設計過程,這3步曲分別可以定義為:

  1. 問題定義(簡稱“Why”);
  2. 問題求解(簡稱“What”);
  3. 思路拆解(簡稱“How”),簡稱“2W1H”。

1. Why

為什么要做…

解決了怎樣的問題

2. What

通過“X”來解決

3. How

怎樣拆解“X”?

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

“Why”和“What”主要側重戰略層面的思考,如何發現并定義問題,并能夠給出創造性的解決方案;“How”主要側重落地層面的推演,通過邏輯層面的枚舉、關聯以及權衡,梳理出解決方案可能涉及的每一個脈絡,并以文檔的形式進行產出,為開發、設計提供行動指南。

關于需求落地

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

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

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

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

第二步:確定細節

1、確認主要流程中業務邏輯細節

(1)提升體驗

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

(2)商業增值

有助于完善產品商業模式,如相比與普通用戶,Momo會員可以享受33項個性化特權。

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

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

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

2、確定主要流程界面的10種狀態樣式細節

(1)初始狀態

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

(2)等待

只要涉及到數據的提交、上傳,就需要用戶等待。靜止的事物會讓覺得自己行為沒有得到響應,通過動畫傳遞當前系統正在響應自己的行為。

(3)輸入

通過怎樣的方式向系統傳達指令?

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

結合數據類型,選擇合適的輸入方式。

需要輸入姓名、賬號之類的高自由度的數據,可以選擇輸入框或者第三方信息授權輸入方式;

需要輸入密碼之類的隱私性數據,可以選擇輸入框、手勢譜、語音、圖像、視頻、指紋等;

需要輸入“0-1”數據可以考慮開關;需要輸入特定緯度下的數值信息可以考慮滑塊、滾動框;需要輸入泛緯度數據可以考慮標簽、篩選器;

需要輸入“lucky”信息可以考慮隨機個性化輸入方式

(4)空態

只要是涉及到數據呈現的界面,都極有可能存在空態頁,提前準備好空態頁,避免開發再問你要或擅作空態處理,顯得自己很不專業。

(5)有數據

如何呈現已有數據?

移動端常見的數據呈現方式有:列表、陣列網格、卡片、泳道、瀑布流(單/多)、抽屜、折疊、數據可視化、3D球列表等。

(6)過多數據

數據太多,怎么顯示?

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

(7)用戶行為數據的提交

涉及到用戶行為數據的提交,需要有結果反饋。

(8)表單

涉及到連續任務時,最好用表單結構。

(9)事件結束

事件的結束不等于行為閉環了,深入用戶使用場景,揣摩用戶可能還想干嘛?最終能夠閉環每個事件。

(10)無網絡

無網絡是最常見的異常狀態,精心設計的無網絡狀態會緩解用戶的沮喪,至少不會將這一切歸咎于自生的錯。

3、綜合所有的脈絡信息最終確定最合理的脈絡細節

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

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

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

(1)最上方的泳道卡片被添加后是否需要消失?

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

(2)消失后還需要再出現嗎?如果再出現,時機又是什么?

如果不出現,就意味著我很快就會把通訊錄好友都點完,之后推薦泳道就空了;但如果出現,就意味著我可以重復點一個好友多次。我們發現這兩個假設其實互為正負關系,因此只需權衡兩端的優劣,就可以確定該關系下的脈絡細節。

① 重復添加好友–脈絡信息分析

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

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

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

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

(3)既然是單向好友體系,那么還需要好友申請頁嗎?如果需要,申請頁中的用戶狀態分別有哪些?

① 脈絡細節-需要驗證頁

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

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

那么問題來了,用戶B點擊“同意”Button后,好友A會消失嗎?如果不消失,此時的“同意”Button應該切換成什么狀態?

② 脈絡細節-新的好友頁

假設消失,如果此時B刪除了A,B再去添加A,A的新的好友頁更新B的好友申請,此時A出現了重復添加了B的操作,即消失細節不可行;那假設不消失,新的好友頁有該是怎樣的細節呢?

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

再回到我們之前假設的場景:B刪除了A意味著B不再是A的粉絲,所以這時A的“新的好友頁”不再有B,但此時B依然是A的好友,即A還在關注B,這時B又添加A,即B又重新關注了A,這時AB關系是互為關注,依據之前的類比,AB互為關注應該顯示“用戶B 已添加”,即這時在B的“我的好友頁”顯示“用戶B 已添加”。

小結

落地永遠比想法更重要,置于如何落地,首先你得對問題的解決策略做到心中有數,能夠梳理出其中關鍵的業務流程,之后再去聚焦每個流程中的細節。

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

#專欄作家#

UE小牛犢,微信公共號:UE小牛犢,人人都是產品經理專欄作家。關注產品思考、用戶體驗分析、交互研究,致力于UX方法論的探索和實踐。

本文原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Pexels,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 有點意思

    來自浙江 回復