別盲目聽從你的用戶


關於傾聽用戶,Paul Buchheit是這么說的:

我用了一天的時間就做出了第一版的Gmail。它一開始並不起眼。我所做的,也不過是把我所有的郵件放進Google組(Usenet)的索引引擎里。我把它發給幾個人看了,他們評價說這還是挺有用的,但如果除了我的郵件之外也能搜他們的郵件,那就更好了。於是我開發了第二版。在將第二版發布之后,人們開始想要回復郵件的功能。於是我開發了第三版……在Gmail正式面世之前,這個過程實際上在Google內部持續了好幾年!

一般創業公司不太會有成千上萬那么多的內部用戶。因此,把產品盡早公開發布出去是很重要的。當FriendFeed在10月份准發布(內部測試)的時候,這個產品其實才開發了大概兩個月(而且99.9%的代碼是由Bret和Jim兩個人寫的)。從那以后,我們做了大量的改進。試想如果我們當初沒有提前發布,可以肯定的是,我們最終做出來的產品絕對不會像現在這么好。什么原因呢?因為我們找到了用戶,而且我們傾聽來自他們的反饋,我們很清楚地知道我們的產品哪方面做得好以及哪方面做得不好。

傾聽用戶是一件很微妙的事情。用戶常常不知道他們想要什么,即使知道,他們也未必能夠說得清楚。溝通永遠是個問題。但不管怎么樣,你都不能忽視用戶。大部分人在發現你的軟件或網站滿足不了他們的需要時,都只是靜靜地走開,而且永遠不會回頭。因此,那些熱心給出反饋的用戶值得你去注意和尊敬。他們很積極,以幫助你設計產品為己任。如果你不認真傾聽,並且有禮貌地回應所有的用戶反饋,那你注定會失敗。

拒絕傾聽用戶是很不明智的。然而,我們給“可用性”設定的第一條規則是“不要聽從用戶”,這不是自相矛盾嗎?

如果想知道哪個設計方案更好,只須用戶在操作界面上嘗試去完成他們的任務時,你在一旁仔細觀察。這個方法是如此之簡單,以致於很多人都熟視無睹。他們不敢相信,認為可用性測試一定還有其他更為高深的東西。然而,這里面究竟有哪些基本原則呢?我把它們歸結如下:

·       觀察人們的實際做法;

·       不要相信人們說的他們做了什么;

·       絕對不要相信人們預想的他們將來可能會做什么。

我是認同Paul的,但他的話容易讓人誤解。Paul曾在一篇文章里說過相關的這么一段話,“我們心里很清楚什么東西在正常工作”,它實際上暗示了“衡量”和“關聯”兩個要素。如果你的產品能夠產生詳細的日志來記錄用戶的實際操作,那么就沒必要當面去觀察他們了(盡管你去當面觀察也無妨)。在你收集了用戶的反饋之后,要把它們跟記錄那些用戶實際操作的數據關聯起來。

不要單純地實現來自“用戶代表”或者“業務分析師”的功能需求。把可用性搞砸最常見的做法,就是只聽用戶說的,而不去看他們真正做的。需求說明書里定義的常常都是錯誤的。你必須快速地把需求轉變成原型程序,然后將具體的東西展示給用戶,以確認那是否就是他們真正想要的。

僅憑用戶反饋就采取行動是有問題的。哪怕你出於多么美好的意圖去猜測。如果你能根據“白紙黑字”一樣可靠的數據而采取行動,為啥還要靠猜呢?把用戶反饋和詳細的使用數據結合起來,然后再去對你的應用程序或網站采取必要的改進措施,這才是正確的做法。

讓我們一起來看看Valve軟件公司所做的硬件調查表吧。一直以來,游戲玩家對支持非常高的寬屏分辨率呼聲很高,比如1920 x 1200或2560 x 1600。這是完全可以理解的,畢竟他們在采購高端游戲裝備上花了很多錢。但是,對於絕大部分人來說,他們究竟在用哪個分辨率呢?


譯者注:Valve是一家位於美國華盛頓州的軟件公司,專門開發電子游戲,代表作品有《半條命》、《軍團要塞》、《反恐精英》等。

基於這份對130萬Steam用戶的調查表結果顯示,大概只有10%的游戲玩家擁有很高分辨率的寬屏顯示器。當然,可能會有其他方面的原因促使你仍然去滿足他們的要求,比如說,這10%的人很可能是這個游戲最忠實的玩家,他們具有很大的影響力。但有了真實的數據去印證用戶反饋的問題,它能支撐你所采取的行動,以確保你的開發經費用在了刀刃上。最后你還要做的是,在幾乎沒人使用的功能上削減開發成本。而這些都得靠分析使用數據來幫你決策。

譯者注:Steam是一個游戲整合下載平台,最初是由Valve公司請人開發的。它原先只為Valve旗下的游戲更新內容而用,不過現在已經發展成為一個全球最大的綜合性游戲下載平台。

Valve公司同時也在為它旗下的眾多游戲——比如第二版的《軍團要塞》(《TeamFortress 2》)——收集詳盡的關於游戲玩法的統計數據。

我們已經習慣於依賴從玩家那里得來的書面反饋,以幫助我們決定游戲里需要特別改進的地方。而最近,Steam允許我們收集比以往更多的信息。第二版的《軍團要塞》也自帶了一個匯報機制,它可以詳細地告訴我們用戶是如何玩游戲的。我們把收集到的這些數據共享出來了,因為我們覺得大家會發現它很有趣,而且我們也希望盡早把一些嚴重的問題定位出來,並最終開發出一個更好的產品和用戶體驗。

報表的第一段給出了每個兵種所使用時間的一個統計,它揭示了第二版《軍團要塞》的一個問題,而且我認為,這是一個通過再多的玩家反饋都不可能暴露出來的問題。

偵察兵

17.5%

工程兵

17.3%

普通士兵

15%

爆破兵

10.5%

狙擊手

10.1%

重裝兵

8.5%

間諜

8%

噴火兵

7%

醫療兵

5.5%

這個問題就是,醫療兵在實際的作戰過程中被嚴重忽視了。我猜這是因為醫療兵並不直接參與戰斗,所以他們並不像爆破兵或士兵那樣激動人心。然而這是令人遺憾的,因為醫療兵的治愈能力對於贏得一場戰爭常常是很關鍵的。Valve公司接着做了什么呢?他們發布了一系列跟醫療兵相關的作戰取勝法,以鼓勵玩家更多地選用醫療兵。這就是基於真實世界的玩家數據而進行的迭代式游戲設計!

使用詳細的游戲玩法度量來提煉游戲設計的做法並不是新創的。Bungie公司早已對第二版和第三版的《光暈》(《Halo》)進行了全面的可用性測試。


4月份的時候,Bungie公司發現,在第三版《光暈》的一個叫瓦爾哈拉殿堂(Valhalla)的多人游戲關里存在一個令人不安的問題。

玩家的死亡數(在上面的“熱量圖”里用深紅色表示)呈現出向左邊基地傾斜的趨勢,這暗示着從右邊偷襲的軍隊可能占了什么便宜。在對這個圖片復審之后,設計師最終修改了地形,以使得交戰雙方的機會均等。

譯者注:瓦爾哈拉是北歐神話中死亡之神奧丁款待陣亡將士英靈的殿堂。

我們再一次看到了統計數據的力量。試想一下,如果光靠玩家主動告訴我們的反饋,我們怎樣才能發現地圖不平衡這樣非常基本的問題呢?我不知道這是否存在一丁點的可能性。

去看一看,你的應用程序或網站開始以一種合理的方式收集有用的用戶活動數據了嗎?別誤會我。我始終認為,用戶反饋是很重要的。但絕對不要“單純”依靠用戶反饋來指導你的行動。我們應當總是通過某些用戶活動數據,來印證和支撐有價值的用戶反饋。忽略用戶反饋可能讓你最終難逃失敗的命運,但盲目地聽從每一個用戶的請求也會讓你必敗無疑。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com