基于“強反饋”的產品設計
去年的這個時候剛剛開始接觸產品工作,基本是自己探索,那時候非常稚嫩,認為原型一定要畫好,所以一定得學好Axure,但是現在明白,工作中的所有事項都要考慮優先級和時間,就像html標簽需要配著屬性一樣。所以現在對待原型的立場是:一切以溝通清楚為目的??梢砸痪湓捳f清楚的,就不要畫圖;可以手畫說清的,就不要用軟件;低保真能說清楚的,就不要高保真。
當然,有的時候對方清楚是當時清楚,過幾天做到那里的時候可能就不記得你當時什么意思了,這種情況也要考慮,如果到時候兩句話就可以讓他回憶起來,就沒必要花一個小時時間寫個PRD。至于要不要有一份存檔備份,也是取決于產品開發進度是否正常推進以及有沒有其他優先級更高的事情。而更重要的一點是建立“產品方法論”。
我理解的“產品方法論”是指導產品工作的一套完整框架,工作流程上能讓你時刻知道自己在工作流的哪個環節,下一步要做什么、能做什么。
除了產品工作流程之外,“產品方法論”中更重要的一個方面是建立需求與產品Feature之間的對應體系,這里的需求我把它分為兩個層面——淺層需求和深層需求,比如用戶抱怨產品沒有評論區,這個時候你覺得這個是個需求,滿足這個需求就加了個評論區,但實際上用戶可能要的不是或者不只是評論區,而是一個能表現自己的地方,所以可能要加的不是“評論區”,而是比起“評論區”更能讓用戶表現自己的一個Feature,或者跟“評論區”配合,一起上幾個組合Feature,比如頂、踩、分享、Feed流展示等等,絕用戶要一個評論區,就給一個評論區。當然,“能表現自己的地方”可能還不是最深層的需求,還可以往下適度深入分析,但如果往下深入到馬斯洛五類人類需求,對應到產品Feature上就會有麻煩。所以到底深入到什么程度,需要在天分、經驗和試驗的基礎上決定。
今天重點聊聊的是一項人類底層心理需求與產品Feature之前的對應關系,當然具體應用起來需要具體問題具體分析,這里我主要談一般性的東西。
這項底層需求是:得到反饋,這里說的反饋比較廣義,可以理解為發出一個動作之后收到結果。
我們在溝通中最煩的就是自己說完,對方完全沒有反應,尤其是男女朋友吵架,女生一直說,男生當她是空氣,或者倒過來,這時候吵架一般就會升級了,因為沒反饋是人類討厭的。這時候正確的做法是一方說完一個意群之后,對方說對、明白,這就是一個正向積極的反饋。女生叫男生,男生不但答應,還飛奔過來,這也是強反饋。還有我們點一下某按鈕,沒有反應,再點一下又沒反應,再點一下還沒反應,我們就開始罵街了:他媽的怎么沒反應呢?原因還是沒有得到自己想要的反饋。
一個好的產品,需要時間(過去、現在、未來)和空間(場景)兩個維度給予用戶反饋,反饋可以分為積極反饋(比如積分增加)和消極反饋(比如游戲中掉血),即時反饋和延時反饋,同時各種類型的反饋也帶有不同的強弱程度,在具體產品中,應按具體需求設計反饋形式和強度,一般來說,超出用戶預期、又在情理之中的反饋能帶來優秀的用戶體驗。下面舉兩個例子:
彈幕:
用戶打完字確認發送之后,他一定是等著自己的彈幕出來,彈幕出來到離開就是一次反饋的過程,這種即時反饋就讓用戶比較爽。
如果從反饋程度上切入優化這個產品Feature,就可以考慮是不是可以讓彈幕拐著彎(按一定路徑)、打著轉(有一定動作)飄過,能碰到視頻窗口邊緣后有彈擊的效果一定挺爽的,甚至可以讓用戶付費買彈幕效果,但這個Feature可能會帶來負面效果:彈幕太吸引注意,喧賓奪主。但是這個東西單靠想就沒辦法衡量,這個時候就應該把這個Feature想完善之后上線,然后拿數據說話。
微信互動:
玩微信最爽的時刻之一就是看到自己發完朋友圈之后有數字冒出來,這是延時反饋,但是這種反饋的魅力在于具有持續性和不確定性,數字越多、周期越長,反饋也就越強烈,用戶也就越爽。
這種反饋也帶有一種明確性,這里出現的數字肯定是跟用戶相關的贊和評論,而“贊”和“評論”都是用戶相對在意的、想看的,也可以歸為加大了反饋強度。
而微博的互動是這樣的:
除了用戶最關心的“提到”、“評論”、“贊”之外,其他信息(比如微博電影)也會計入信息數量,但其實用戶不是很care這些信息,這樣這個數字給用戶的感覺就不會像朋友圈數字那樣強烈,這種產品設計整體上就弱化了反饋。把現在Message下除了“提到”、“評論”、“贊”之外信息轉移到Me下面,把“好友增加”、“提到”、“評論”、“贊”整合到一處應該是個不錯的辦法。
目前反饋做得最牛的還是游戲,不但有積分、徽章、排行榜等激勵機制,更重要的用產品的過程本身就是一個強反饋的過程,你按一下一個人甚至一支軍隊就動起來,再按幾下一個地方就平了,這種反饋強度超越了現實中你所能掌控的東西,所以會很爽很爽。
所以,我覺得做產品的必須得是重度游戲玩家,從好的游戲里學到最牛的反饋機制,然后靠悟性將其應用到自己負責的產品中,不失為產品經理的一種成長途徑。
以上是需求與產品Feature的對應關系的一個例子,其實“得到反饋”這個需求就有點太“元”了,以至于很多Feature都能歸到這個需求上,在實際應用中會有難度,但這個到這個需求層級基本上算是找到根源了,思路會開闊許多??傊?,希望能盡早建立起一個恰當的對應關系體系,對產品狗狗們的工作是特別有好處的。
作者:郝冠清(微信號stormHao92),北京語言大學翻譯碩士,語智云帆產品經理,一個月互聯網產品設計經驗, 負責翻譯相關互聯網產品設計工作。
本文由 @郝冠清 原創發布于人人都是產品經理。未經許可,禁止轉載。
更偏向與在重大版本或者新功能要用axure去做帶交互的高保真原型。
作用在于:
1. 進入開發之前給用戶做“可用性測試”,確保開發的產品是可用的流暢的。
2. 更專業規范,評審會時更有說服力= =
3. 能對技術,特別是前端的實現有深刻認識,避免的坑。
如果只用語言說,很容易考慮不周到。自己花時間梳理會更清晰。而且現在大家都喜歡用墨刀做可用性測試,但是Axure功能強大太多啦。
明白,學習了,感謝!可否留個微信?或者您加我?