淺析如何面對不友好需求
前幾天做夢,突然夢到了很久之前看到的一個吐槽產品經理的小故事,或許是現在被產品“虐”習慣了,感覺看問題會有不同的角度,于是,憑著記憶去搜了這個故事重新看了一遍,果然有一些以前沒有想到的結論。
案例:
今天上班,突然接到產品經理過來提了一個需求,說要在知乎的首頁正中間放一個“幫助”按鈕,他畫了一個原型圖大概是這樣:
設計師(以下簡稱UE)第一反應是:這…好像不太好吧?
產品經理(以下簡稱PM):為什么不好?用戶如果有問題,他就可以點這個按鈕尋求幫助,這很需要。
UE:但是首頁最核心的任務是提供流信息,為用戶提供內容。而且這個頁面沒什么學習成本,用戶很容易就能理解,不需要幫助按鈕吧?
PM:那是一部分用戶覺得容易理解,那如果用戶真的有問題、不會用,總要有一個入口讓用戶點吧?
UE:這個幫助功能有這么重要嗎?放在首頁這么正中心的位置,擋住了后面正常內容,用戶又不需要的話不是干擾主流程和大部分沒有問題的用戶了嗎?
PM:那加個取消的按鈕吧,用戶如果不需要他可以選擇關閉,需要再去點。
于是,PM 快速畫了這樣一張圖:
UE:不管怎么說,幫助都只是一個輔助功能,肯定不能放在最首頁的位置,這最多是一個緊急情況下的選項,肯定不是用戶的訴求。
PM:你怎么知道不是用戶的訴求呢,我作為用戶就挺需要的,我問了身邊幾個朋友也都說需要。
UE:不是你說需要就需要,你們兩三個人能代表用戶嗎?
PM:那你一個人不需要,也不能代表用戶啊!
UE:……
PM:那這樣,快速做一個版本上線做 A/B Test 吧。看看有多少人點擊幫助、多少人點擊取消,再看看對首頁的點擊率有沒有影響,這樣總可以吧?
UE:這種需求不用測也……
PM:總得給個實驗的機會吧!說好的用數據說話呢!
于是,大家吭哧吭哧制作了一版 A/B Test,上線一周后,數據反饋搜集完成。統計結果是這樣的:
PM:數據出來啦!幫助的點擊率不是最低啊,而且比取消按鈕點擊率高,看來用戶果然還是很需要的。而且,整個頁面以前的“更多”按鈕竟然只有2%的點擊率,要下也肯定下它,不應該下幫助功能。果然,還是要靠數據說話的。接下來,讓我們再多花點精力把幫助功能做好吧!
案例描述結束
當然其實其中不乏夸張的成分存在,大家只當個故事聽聽就行,只要是在互聯網公司工作的人都能感覺出來,需求有問題,之后許多人會開始故事中的設計師一樣,糾結在用戶有沒有這需求,需求的優先級高不高這些問題上??梢哉f問題確實就出在這上面,但是設計師所提及的想法過于表面,沒有深挖,我們不妨來看看這個需求的本質是什么。
一
公司里的男哥(感謝李尚男男哥給了我很多的想法)曾經告訴過我,當你拿到一個產品經理的需求的時候,應該要做的是,完全摒棄一切產品所提供給你的解決方案,然后去和產品經理了解兩個問題:
- 產生這樣需求的背景是什么?
- 用戶是在何種情景之下進行的該操作?
由此,我們與產品討論的方向就不應再局限于是不是放在首頁這樣的問題上,而是去挖掘背景和原因:
- 是不是最近產品出現了重大bug又或者說最近新增了什么業務流程比較復雜的功能,讓用戶無法獨立的完成操作?
- 又或者是不是“幫助”功能的點擊量突然猛增?那么去向幫助頁面點擊率最高的預設問題是什么?普遍反饋的問題又是什么?
通過這樣的方式去尋找需求的共同點,會比否認他在首頁放幫助的效率更高,如果是因為業務流程復雜,可以通過第一次點擊時出現新手引導來解決,如果是因為bug或者用戶大量反饋產品存在的問題,那么本質就應該去解決問題,而不是提供反饋的入口。
結論:無論產品丟給你多么精致的方案,請忽略不計,一切待得自己重新了解和評估過后再說。
二
要相信數據,但不要過分相信眼前的數據!
案例中,經過A/BTest后,產品給出的數據可以看出,在首頁中幫助的點擊率并不是最低,同時,幫助的點擊率還略高于關閉幫助的點擊率,就證明這個需求還是有許多人需要的。如果是沒有經驗的設計師面對的這樣的數據可能一下子就懵逼了,無法反駁。
但是,但是,但是,敲黑板劃重點。
- 測試周期太短,在首頁那么顯眼的位置出現新功能,有較高的點擊率是正常的想象,可以預見,把測試周期拉長至1-2個月的時候,這個按鈕的點擊率會降低很多;
- 幫助的點擊率還略高于關閉幫助的點擊率并不能說明什么,可以認為有部分人是因為好奇而點擊進入,通過返回來結束,并不是通過關閉按鈕,所以這個數據比較這并不能說明什么;
- 數據是無法單維度分析的,我們僅看到點擊率,而更應該關注的轉換率和留存率呢?只有3個數據都得到了好的反饋才能證明這個需求是真需求,功能是成功的。
三
不要試圖用否認需求的方式來否認方案。
“我作為用戶就有訴求,你沒有訴求也不能代表大家都沒有訴求”
我想,互聯網人應該都聽過別人拿這句話懟你。這句話其實是無解的,任何需求都可以被認為是有訴求的,這無法反駁。因此否認需求就變的沒有意義了,用辯論的技巧來說叫做—-證有不證無。
(關于這個證有不證無可以看看奇葩說或者蔡康永的說話之道都有描述到,這里就不贅述了)
因此我們要假設需求成立,而去了解需求的背景,目的等等,再通過優先級、權重等因素來得到更好的解決方案,而不是直接否認它。
四
損招
這是在這個故事下面看到的比較有趣的評論,雖然是損招,但是感覺好用?。?!
我們要嘗試更多的向上溝通或者多點溝通,而不是點對點溝通。遇到這個問題的時候可以拉很多人來討論,拉領導來討論,拉牽扯到相關的產品經理來討論,由大家一起發表看法。比如案例中如果設計師拉來負責首頁的產品經理說”他要搶你流量”,你看他們不得先PK一遍?而你只需要從他們的PK中去獲取更多等訊息,為之后雄起做好準備!
(損招成不成功不敢保證哈,但是值得一試?。?/p>
最后,希望每一個設計師都能拋開產品給的方案,更多的關注需求本身。
共勉
本文由 @endlishted 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 unsplash,基于CC0協議
11
感覺這是被產品被黑的最慘的一次
感覺舉的不恰當,產品像運營或者編輯,UE像產品。
才發現沒有“贊評論”的功能,求增加,我要贊你
這個產品的腦袋裝的是屎嗎,放其他地方不好?這和web廣告有什么不同,老子想看的是內容。這種產品早該開了。
這個幫助想解決什么問題?我覺得先把這個問題想明白,在想到底放不放,放在哪里,會更好些。
我覺得,對于太過復雜的操作流程,放個幫助還不如放一個演示視頻。
有好有壞吧。幫助可以篩選想看的內容,而視頻只能從頭播放,比較浪費時間。
如果看數據說話
首先要看的是
日活
然后其中新用戶/老用戶占比
新用戶中需要這個的占比(這個需要test)
吧。。。
是的。所以數據從來都是多維度的看。
笑死了,笑完又陷入了沉思,哈哈
燈光,音效,這位同志,請說出你的故事。
別的不說。分享一下??蛻艉陀脩暨€是有差別的。
一般來說用戶都是對的,客戶都是…的!
這位UE有產品的思維 這位產品有運營的思維 哈哈哈
首先在美觀方面我就覺得欠妥。
哈哈哈。為了凸顯矛盾,把矛盾夸張化。
受教了。當我看到pm的需求時,回答跟ue一樣。
沒有說服他人,是因為你的理由還沒有充足的說服力。
是的。所以要從最底層的需求去研究。而不是一上來就去否定表面的東西。
贊同
說的在理,看問題多關注原因,從源頭剝繭抽絲,抓本質,不被表象迷惑。贊
同意,產品本身不直接產出,營造團隊內良好的多向溝通環境也是產品的日常工作之一。