從錯誤中汲取經驗–產品設計案例分享
小編今天看到一篇譯文是有關產品設計案例分享的內容,個人從中獲益匪淺,因此分享給大家,希望大家能夠從中汲取經驗。
譯文:Buffer是一款幫助你在Twitter、Facebook等平臺上更高效的發布內容的應用,到目前我們已經有超過50萬的用戶了。兩年前剛剛開始打造這個產品的時候,我們就已經做好了充分的思想準備去面對各種挑戰,包括設計開發過程中會遇到的障礙以及可能犯的錯誤。
我們始終覺得,在項目當中犯錯是在所難免的;只要能夠從中學到一些東西,這些錯誤就能引導我們向正確的方向前進。從某種程度上講,將我們的產品一點點推向成功的也許正是一路上所犯下的那些錯誤。
重要的設計原則
在開始討論我們從錯誤當中學習到的那些經驗之前,我想先來聊聊我們的一個重要設計原則:
先驗證,再開發。
接下來具體說說是怎么回事。
我們打造Buffer的初衷是創建一種“聰明”的方式,讓用戶可以更高效的在Twitter等社交網絡平臺當中同步發布內容。這個想法剛剛冒出來的時候,我們的創始人Joel Gascoigne立刻開始著手寫代碼,而不是首先去驗證想法。在寫了幾分鐘之后,他才意識到這可能不是正確的方式。
接下來,Joel為這個目前還不存在的產品創建了一個介紹頁面,并把鏈接放在Twitter上進行傳播。對這個想法真正有興趣的潛在用戶會通過鏈接來到介紹頁面;在他們點擊了“服務方案及價格”按鈕之后,接下來的一個頁面會告訴他們,產品目前還沒有完工,請留下郵箱以便在產品上線后的第一時間獲得通知。
從這件事情出發,我們在接下來的歷程當中逐漸歸納出了三點最重要的設計原則及經驗:
- 整個產品或某個新功能的第一版要盡量保持最小化。
- 做好心理準備:項目很可能是長期的,而且會涉及到多次轉型。
- 任何新的主意和想法都需要首先進行驗證。
聊過了總體上的經驗心得,接下來,我將通過一些實際的例子向大家更加具體的介紹一下我們在項目當中所學到的那些東西。
第一課:流程應該聚焦在“用戶保留”而不是收益上
關于用戶體驗,我們在項目早期學到的重要一課,就是要將流程聚焦在“用戶保留(user-retention)”而不是產生收益上。
我們是怎樣了解到這一點的呢?不妨先來看看Buffer上線之后最初版本的注冊申請流程:
- 用戶在介紹頁面點擊了“服務方案及價格”按鈕之后,會被引領到一個介紹具體服務類型的頁面。
- 在這個頁面里,用戶需要在免費或付費方案中做出選擇。
- 選擇了服務類型之后,用戶需要填寫用戶名、郵箱地址等信息,完成注冊。
當時,確實有不少用戶會選擇付費方案,這看上完全去不是壞事。不過我們很快發現,這類會在實際使用產品之前就選擇付費方案的用戶的流失率是非常大的。其中一部分人在付費之后幾乎不怎么使用產品,有些甚至還退訂了付費服務。
于是我們試著修改了這一流程,不在這里要求用戶進行方案選擇;我們對自己說:“還是首先讓用戶自己去體驗產品并判斷Buffer帶給他們的價值吧,在正式使用之后再鼓勵他們根據需求升級到相應的付費版本好了?!?/p>
修改后的流程就是大家現在可以在Buffer的網站當中看到的:用戶可以通過他們的第三方賬號直接登錄并體驗免費方案中的所有功能,完全無縫的即刻開始使用產品。
相關流程的重新設計產生了以下兩方面的結果:
- 有更多的人開始使用我們的產品,因為我們去掉了服務方案選擇頁面及相關的注冊流程,減少了不必要的障礙。
- 有更多的人升級到了付費方案,因為他們可以很直接很容易的進入使用狀態,發現其中的價值,決定與我們并肩通行。
后來,我們對產品做了很多改進,包括增加了更多的免費功能,另外產品的核心功能始終是免費的。只有確信用戶已經體驗到足夠多的價值,我們才會向他們推薦付費的升級方案。
聚焦于用戶保留,這是我們學到的重要一課。
第二課:社會化登錄比傳統Email登錄更有效
為了提升主頁當中的轉化率,我們做了很多嘗試,并進行了一系列的A/B測試,結果都不是很理想。最終,我們決定嘗試社會化登錄的方式,即允許用戶通過他們的Twitter、Facebook或LinkedIn的賬戶來直接登錄。
畢竟,Buffer這款產品就是為了方便用戶同步在Twitter、Facebook和LinkedIn當中發布內容用的,所以這樣做也非常符合邏輯,用戶可以通過他們的相關賬號直接使用Buffer,減少了不必要的麻煩。
出于對比的目的,我們來看看Buffer在使用社會化登錄之前所采用的傳統注冊方法:
這一改變極大的推動了用戶量的增長,轉化率提升了將近50%,實際上在切換登錄方式的當天,日增長數就由500變成了800的樣子。
第三課:盡早驗證每一個假設
我們曾經有一個重新設計瀏覽器插件的主意,它最終失敗的很慘。
瀏覽器插件是整個Buffer產品的一個重要組成部分,它可以幫助用戶直接將Web頁面上的內容添加到自己的“buffer”當中并分享到社交平臺,整體體驗非常棒。
所以很自然的,我們會將注意力放在瀏覽器插件上,希望盡可能的對其進行改進,實現一些更酷的點子。不過在改進的過程中,我們似乎又撿起了過去的一些壞習慣,犯了一些本該避免的錯誤。當時的步驟是這樣的:
- 我們識別出Buffer的瀏覽器插件中存在的一些問題,頭腦風暴了想要改進的地方。
- 接下來,我們花費了大量的時間與資源,重新設計并開發了全功能的新版本插件。
- 完工之后的測試當中,我們發現新版本插件給用戶帶來了極大的困惑。
- 最終我們決定放棄這個版本的插件。
各位在下圖當中看到的就是這個永遠沒有上線的失敗作品:
可以說,正是這次失利讓我們將“盡早驗證每一個假設”的原則深深的印在了腦海里,成為了今后的一種習慣。
如今,我們要改進產品或是要實現一些新功能時,會通過以下步驟進行:
- 識別已有問題,確定需要改進或新增的點。
- 與現有用戶進行溝通,了解他們是否在使用過程中也遇到了這些問題。
- 想法得到初步驗證后,快速制作線框稿或低保真可交互原型。
- 再次與用戶進行溝通,向他們展示原型,觀察他們的交互行為。
- 重復這樣的過程,直到最終確定設計方案。
- 持續追蹤各種指標,保持與用戶的溝通,驗證新版產品的表現。
來源:Be for web
- 目前還沒評論,等你發揮!