一個難以拒絕的設計需求

//以下內容，純屬虛構，如有雷同，純屬巧合。

今天上班，突然接到產品經理過來提了一個需求，說要在知乎的首頁正中間放一個「幫助」按鈕，他畫了一個原型圖大概是這樣：

設計師（以下簡稱UE）第一反應是：這…好像不太好吧？

產品經理（以下簡稱PM）：為什麼不好？用戶如果有問題，他就可以點這個按鈕尋求幫助，這很需要。

UE：但是首頁最核心的任務是提供流信息，為用戶提供內容。而且這個頁面沒什麼學習成本，用戶很容易就能理解，不需要幫助按鈕吧？

PM：那是一部分用戶覺得容易理解，那如果用戶真的有問題、不會用，總要有一個入口讓用戶點吧？

UE：這個幫助功能有這麼重要嗎？放在首頁這麼正中心的位置，擋住了後面正常內容，用戶又不需要的話不是干擾主流程和大部分沒有問題的用戶了嗎？

PM：那加個取消的按鈕吧，用戶如果不需要他可以選擇關閉，需要再去點。

於是，PM 快速畫了這樣一張圖：

UE：不管怎麼說，幫助都只是一個輔助功能，肯定不能放在最首頁的位置，這最多是一個緊急情況下的選項，肯定不是用戶的訴求。

PM：你怎麼知道不是用戶的訴求呢，我作為用戶就挺需要的，我問了身邊幾個朋友也都說需要。

UE：不是你說需要就需要，你們兩三個人能代表用戶嗎？

PM：那你一個人不需要，也不能代表用戶啊！

UE：……

PM：那這樣，快速做一個版本上線做 A/B Test 吧。看看有多少人點擊幫助、多少人點擊取消，再看看對首頁的點擊率有沒有影響，這樣總可以吧？

UE：這種需求不用測也......

PM：總得給個實驗的機會吧！說好的用數據說話呢！

於是，大家吭哧吭哧製作了一版 A/B Test，上線一周後，數據反饋搜集完成。統計結果是這樣的：

PM：數據出來啦！幫助的點擊率不是最低啊，而且比取消按鈕點擊率高，看來用戶果然還是很需要的。而且，整個頁面以前的「更多」按鈕竟然只有2%的點擊率，要下也肯定下它，不應該下幫助功能。果然，還是要靠數據說話的。接下來，讓我們再多花點精力把幫助功能做好吧！

案例分析：這是一個非常極端的例子，在這個例子中，如果把測試時間拉長到一個月，一定可以看到「幫助」按鈕的點擊率逐步下降、「取消」按鈕的點擊率同步上升，這幾乎是一個可以預見的結果。而且，我們也可以通過觀察用戶點擊進入某個按鈕之後的停留時間、轉化率來側面表現一個功能的時機效果。

在這個案例的需求提出過程中，我們看到 PM 使用的一些常見的說服手段，比如「加的這個功能用戶如果不需要就關閉，需要就可以去用」、「我和身邊的朋友都覺得挺需要的」、「總可以上線做測試看數據吧？」等等。在這個極端例子中，我們很容易預判哪些理由是站不住腳的，以及這個一看就不可能成立的需求本身。

然而在實際產品設計中，有很多很多的案例不會這麼黑白分明，設計師、產品經理、研發工程師，幾乎沒有人能拍胸脯說自己所表述的一定就是用戶的訴求。而這時，如果需求方用這樣的方式來說服對方，可能真的很難擋住。也許最後就被那句「總允許上線測試吧」給說服了。

而真實產品環境中，一兩個新功能的加入在一段時間內真的很難產生明顯的數據影響，甚至用戶因為新鮮、好奇反覆點擊反而拉高了數據。這在復盤中，對唯數據論的從業者是非常致命的。

你問我那到底怎麼辦——怎麼判斷功能究竟是不是用戶所需要的，怎麼判斷數據是否具有參考價值？

很慚愧，我現在也不知道，等到我搞清楚的一天，再來分享給大家。

加油！