面向場景而非功能進行設計
前段時間看到過老黃 (三節課聯合創始人黃有璨) 關於共享經濟的一篇文章,裡面提到了一個用來判斷是否為偽共享的模型,即自然流量+隨機消費,滿足這兩個條件則可看作“偽共享”。
在這個模型中,前者指的是與傳統行業一樣看天吃飯,純粹依賴自然流量,沒有辦法很好的將需求端和供給端集中起來,後者指的是隨機性的需求,即使用者本來沒有這個需求,是在某個環境中被激發出來的。
其實這個模型用來判斷很多專案都是成立,滿足不了前者說明沒有辦法很好的解決使用者的問題,也就沒有辦法很好的形成需求閉環,滿足不了後者,說明這個需求沒有特定的場景,很有可能需求本身就是個偽需求。
這篇文章重點談論的是後半句,也就是非隨機需求,即使用者在特定場景下的具體需求。沒有場景,何談需求,沒有需求,何來解決方案,何談產品價值與使用者價值。
做產品的本質就在於通過解決供需問題來創造新價值,進而打破舊的利益平衡,讓己方在新的利益平衡中佔據有利的地位。
先來說個很爛的老梗,福特與馬的故事,使用者總是會告訴你需要一匹馬,一匹更快的馬。那使用者是在什麼情況需要這匹馬的呢?是在兩座城市之間奔波時,是在賽場上,還是說在耕地的時候?
這三種不同場景下對應的需求可能都是更快,但是對應的解決方案可能千差萬別,在城市之間奔波時使用者需要的可能是汽車,在賽馬場上使用者需要的可能就是一匹更快的馬,而在耕地的時候可能使用者需要的其實是個拖拉機…
你看需求的場景如此重要,會導致失之毫釐,謬之千里。那場景到底是個什麼東西呢?
場景是什麼
先來看一個錘子釋出會上他們產品經理分享的一個案例, 今年錘子釋出會上介紹了一個偽裝來電的新功能,這個功能是提前設定好時間,然後在特定的時間會有電話打進來,並且可提前設定好打進電話的內容和語言種類 (諸如各地方言、普通話之類) 。
當時錘子的產品經理朱蕭木分享了這個功能拍板的過程,最開始這個功能沒有確定要做,因為錘子的另外一個產品經理覺得這個功能沒有對應的場景,沒必要做,所以兩個人就爭執不下。
後來朱蕭木就拉著另外一個產品經理開會,說不討論出來一個結果兩個人就不出來。結果幾個小時之後,另外一個產品經理說我好希望有個人能打電話進來,於是後來就有了這個偽裝來電的功能…
最開始錘子的另外一個產品經理覺得沒有實際場景,不需要做這個功能,然後朱蕭木就拉著他開會,這個時候另外一個產品經理就深切感受到這個場景原來是真切存在的。
那麼問題來了,場景究竟到底是什麼,如何來定義呢?
網上有很多關於場景的定義,感興趣的話可以自行搜尋下,個人覺得用記敘文的六要素來概括最為恰當,既涵蓋了所有的部分,又容易記憶。 這六要素分別就是時間、地點、人物、起因、經過、結果,即在什麼時間,什麼地點下,什麼人因為什麼原因產生了什麼慾望,最終通過什麼手段來滿足這種慾望。
這六要素能夠構成一個完整的使用者故事,在這個使用者故事中,我們可以看看有哪些是使用者的慾望沒有很好滿足的,有哪些是使用者很不爽、有負面情緒的,或者有哪些方式是能夠幫助使用者更好的滿足慾望的,一旦發現了這些,可能就發現了一個新的機會點…
接上文的案例,用六要素展開來看的話:
時間不詳,地點是在會議室,人物是朱蕭木和另一個產品經理,起因是兩個人希望把需求定下來,不討論出來結果就不出來,經過是在一段時間的討論之後另一個產品經理覺得自己想脫身,但是又沒有辦法脫身,結果是覺得這個偽裝來電的功能是有必要的。
從自身的角度來看,這個場景是成立的,那在其他使用者身上這個場景是成立的麼?確定了場景的真實性,之後就是基於使用者量、出現頻次以及重要緊急程度來進行後續的判斷了。
為什麼要面向場景設計
上一節中我們提到了什麼是場景,核心要素就在於時間、地點、人物以及起因、經過、結果。那我們為什麼要面向場景來進行設計呢?除了在引言部分提到的不同場景下相同的需求的解決方案是不同的,主要還有以下幾個方面,只為拋磚引玉,因為肯定還有其他的原因…
避免偽需求的坑
之前的文章中提到過一個需求三角的理論模型,即缺乏感+目標物+消費能力。放到具體的場景裡就是,因為環境激發了某種缺乏感,然後基於環境和個人因素產生了某種目標物,從而產生了獲取這種目標物的動機,這種行動的動機減去使用者需要付出的成本後,最後構成了使用者的行動慾望。感興趣的話可以去看下之前的文章…
如果連真實的場景都找不到,那也就很難激發這種缺乏感,沒有需求的源頭,也就不會有後續的環節。產品歸根到底是需要滿足特定使用者的某些需求的,而需求產生的動機就是因為在某個場景下被激發出了某種缺乏感,連特定的場景都沒有,那這個需求本身很有可能就是一個偽需求…
牢記我們不是目標使用者
慢慢的也算入行了,也越來越不敢隨便分析/評論一款產品了。原因很簡單,因為我既不是產品的目標使用者,又不清楚產品背後的決策環境,甚至都不知道這個功能出現的場景是什麼,要解決什麼問題,連管中窺豹都談不上,又怎麼敢隨便評論。
在設計我們自己的產品的時候也應該時刻牢記,我們不是產品的目標使用者 (如果是也需要注意設計者思維與使用者思維的差異) ,而且我們也不清楚使用者在處理任務時的心理和行為是怎樣的。通過場景分析,我們可以通過講故事的方式來模擬使用者可能遇到的問題,從而發現使用者的心理、行為變化。
不要忽略真實場景
記不清之前在哪本書裡提到過這樣的一個案例,說是哪家行動式裝置廠商為一些戶外愛好者開發了一些行動式裝置。然而銷量並不好,因為這些戶外愛好者去的很多地方根本就沒有信號…
很多時候我們產出設計方案的時候都是在舒適且網路環境良好的辦公室,而我們的目標使用者可能面臨著各種各樣的問題,比如網路訊號不好、任務隨時可能會被中斷、經常需要單手操作等等…面向場景能更好的模擬使用者的真實使用場景,進而更好的處理這些異常問題。
使用者之所以選擇使用某個產品都是因為這個產品能夠滿足Ta的某些需求,而使用者使用產品也是基於某個特定任務的。所以我們在新增新功能時也需要清楚這個功能解決了什麼人在什麼場景下的什麼問題,而不僅僅是為了功能而功能。
如何面向場景設計
上文中也提到了,產品是為了解決某些人在某些場景下的某個問題的,而我們的目標使用者肯定是真實存在的,也就是說這個場景肯定能對映到現實世界中一個具體的人身上的。換句話說就是, 一個人,一個問題,一個方案。
場景列舉
現在的場景大致可以分為三類,一類是原先線上下的場景,目前尚未實現線上化,也就是原生場景,一類是純粹線上場景,也就是網生場景,還有一類就是線上與線下結合的場景,也就是混合場景。這些是大的場景,之後才是小場景,各場景的圖譜可參考下面的圖片。
素材來源於網際網路
小場景指的就是使用者使用產品完成任務的主線流程,以共享單車為例,這是一個混合場景,需要線上與線下相結合,解決的是上班族或者校園學生半徑一公里範圍內的出行問題。整體的主線流程可分為找車→開鎖→騎行→還車,這幾個小場景都是需要與產品發生互動的環節。
場景分析
明確了場景之後,就需要能夠對場景進行更深入的分析了,分析的主要目的是明確這個場景中使用者可能會遇到的問題,並且需要明確使用者要完成哪些任務,進而為使用者提供一些必要的幫助資訊,從而幫助使用者更好的完成任務。
在整個分析的過程中尤其需要關注使用者情緒的變化,因為這是使用者的需求沒有被很好滿足的訊號,也就意味著新的機會點。
接上文共享單車的案例,在找車這個小場景下使用者的主要任務是發現單車,所以產品需要解決的問題就是讓使用者知道車在哪,並且引導使用者去找到車。所以摩拜給出的解決方案就是利用GPS定位來幫助使用者發現單車,同時利用地圖導航來引導使用者去找到車。
場景裡面的其他要素會延伸出一些其他的問題,比如天太黑光線不好怎麼辦 (時間) ,有其他的人把單車騎走了怎麼辦 (人物) ,車壞了怎麼辦 (結果) 。這些都是問題,發現了問題,也就比較容易找到對應的解決方案了。
場景設計
場景設計就是基於場景分析中發現的問題來給出合適的解決方案,在此過程中需要考慮多方面的因素,一方面需要基於使用者的任務流程來考慮,需要能夠為使用者提供合理的幫助和必要的資訊,從而讓使用者更好的完成任務。
另一方面還需要平衡使用者目標與我們的目標,比如使用者的目標是能夠方便的出行,最好價效比高,當然免費更好。而共享單車企業的目標肯定是佔據更大的市場份額,並且能夠盈利,這兩者之間的目標可能是衝突的,這就需要去做合理的平衡了。
此外解決方案還需要考慮優先順序與價效比,資源肯定是有限的,而且對於使用者而言,核心的場景和任務肯定只有那麼幾個,所以核心場景下的問題肯定需要優先解決。比如ofo早期的大黃車雖然造型不美觀,而且也不太好騎,但是依然有很多人在用,因為對於出行這個場景而言,有用是第一位的,其次才是好不好用…
價效比涉及到另外一個問題,那就是成本與收益,成本高收益低而且沒有上升空間的話,那這個方案就需要慎重考慮了。ofo從最早期的機械鎖到現在的單向密碼鎖,一方面是出於保證開鎖率的考慮,另一方面很有可能就是基於價效比的考慮。
以上就是本文的主要內容,從一個模型過渡到場景這個話題,然後從場景是什麼、為什麼要面向場景設計以及如何面向場景設計這幾部分來展開,歡迎斧正、指點、拍磚…
產品學習|交流分享
公眾號ID:產品經理從0到1
長按二維碼即可關注