董 冰
同濟大學軟件學院,上海 201804
隨著互聯網的普及和web 2.0技術的推廣,互聯網產品的數量層出不窮,越來越多的中小企業有能力推出自己的互聯網產品。但是如何確保自己的產品可以從數以萬計的競爭對手中脫穎而出,也就是回答用戶“為什么需要選擇我們的產品”這一問題的時候,除了軟件架構和技術之外,可用性越來越多的成為了衡量一個產品是否能夠成功的標準。進行可用性測試(Usability testing)是提高產品可用性最有效的方法。
那為什么要進行可用性測試?因為通過產品的可用性測試能夠幫助企業:
1)提高銷售和轉化率;2)最大限度的提高用戶滿意度;3)提高品牌忠實度;4)消減客戶服務問題。
什么是可用性測試?可用性測試(Usability testing),是一項通過用戶的使用來評估產品的技術,由于它反應了用戶的真實使用經驗,所以可以視為一種不可或缺的可用性檢驗過程。也就是說,可用性測試是指讓用戶使用產品(服務)的設計原型或者成品(包括網站、原型、iPhone/iPad和Android應用、內部網、應用程序和游戲。)通過觀察,記錄和分析用戶的行為和感受,以改善產品(服務)可用性的一系列方法。它適用于產品(服務)前期設計開發,中期改進和后期維護完善的各個階段,是用戶中心設計的思想的重要體現。
可用性測試采用的是黑盒測試技術。目的是通過觀察人們使用產品來發現產品設計中的失誤以及在哪些區域還有提升的空間。可用性測試一般來說包括獲取4個方面的反饋:效率,準確性,回憶偏差和情感反饋。首次測試的結果可以被定位基線標準,所有之后進行的測試結果可以通過與其進行比較來體現改進。
就如筆者在文章開頭提到,其實所有的互聯網產品都需要進行可用性測試。傳統意義上,可用性測試需要經過專業訓練可用性測試主持人和專門的可用性測試辦公室,同時有最先進的設備(比如眼動儀)來獲取用戶在屏幕上做什么。相較于大公司而言,很多中小公司不具備也沒有能力去對網站開展專業的可用性測試,然而也并不是說做不到最好就不去做,沒有眼動儀,可以用錄屏軟件,況且在項目初期我們只有原型設計的時候,就已經可以從簡易可用性測試中獲得有幫助的數據了。
筆者實習的公司前一段時間進行了簡易可用性測試。本文系測試方法和特性的整理,分為三個部分,測試的時機、測試的方法和測試的要點:
一個互聯網產品的誕生,需要經歷從草圖到原型到視覺到開發再到上線的過程,按照軟件開發的理論,上線前應當經過測試的環節。但也就是這個叫做“測試”的環節,往往可能會成為整個項目的轉折點,各種問題各種BUG在這個環節被曝露出來,而曝露出來的問題可能會造成推翻前面的某一階段的工作,進而造成整個項目的延期。為了避免“集中測試”造成的問題,應盡量將“測試”拆分成始終隨著項目一同前進的行為。
越早開始測試,就能越早的發現一些細微的問題,越早發現問題就能越早的修正。當項目開始草圖階段時,就介入可用性測試,避免在最后時刻的集中測試曝露出積累的過多問題。
在中小企業中,可用性測試可以作為輕量級的測試,每月拿出一個上午的時間來進行測試,每輪測試三個參與者就已經足夠了。我們并沒有采用Jakob Nielsen先生推薦的五個參與者是因為由于這種簡易的可用性測試操作每個月都可以進行一次,所以測試了三位參與者之后得到的反饋已經滿足一個月的工作量了,而且我們還發現三位參與者發現的問題有很多重復的部分,不同的問題比較少,所以經過權衡,我們認為三位參與者對于簡易可用性測試已經足夠。
參與者的選擇標準應該比較寬泛但不能與項目有任何關系,以此來提高可用性測試數據的準確率。
準備階段(腳本,參與者,測試地點和情景):
參與可用性測試的人員:應該有一位主持人來進行測試,1-2位觀察者(不應該超過三個人,因為人數太多會引起參與者的緊張)在可用性測試的準備階段,我們有三樣東西需要準備,腳本、參與者和測試地點。
腳本:腳本的作用是讓主持人在進行測試前進行宣讀。腳本可以使用連接下載。
參與者:這點應該根據產品的特點進行酌情挑選,一般來說,互聯網產品的用戶不需要有極強的專業知識。專家用戶不是理想的候選人,因為他們會將陳腐的想法帶入到測試中來從而影響結果。
測試地點:對于中小企業來說,測試地點只需要一個安靜的會議室足以。
一個可用性測試的流程:
第一步是宣讀腳本,并告知參與者一些測試中的基本規則;第二步是詢問參與者一些關于其背景的問題,這些看似平常的問題可以幫助參與者放松。第三步是講首頁或者進入后的第一個頁面的設計展示給參與者。這可以幫助參與者了解測試中的界面,特別是當測試的頁面還是低保真頁面的時候。
完成任務的時間應限制在35分鐘內。
當參與者完成了任務后,主持人應該花10分鐘來問測試后(Post-questionnaire)問題,其中最重要的是讓參與者講述對于整個設計的第一印象。
測試的要點部分我分為三個階段既測試前、測試中和測試結束后。
2.3.1 測試前的要點
1)最重要的要制定一個任務列表;2)小組討論之后確定最終的任務;3)基于討論好的任務,寫出易于理解的場景;4)為每個場景設置好限制;5)與一個對業務比較了解的專家來進行預測試,以校驗場景的合理性;6)講任務打印出來(可以是一頁一個任務,也可以講所有任務打印在一頁上。這并不會影響測試結果)。
2.3.2 測試中的要點
1)一個可用性測試不得超過一個小時;2)在開始測試的時候,應該把任務和腳本都大聲宣讀出來;3)要從訪談中獲取參與者的背景信息;4)主持人應該扮演導游同時也是心理咨詢師的角色。作為一個導游,主持人應該在正確的時間告訴參與者做正確的事情。而作為一個心理咨詢師,主持人應該不斷重復例如“請告訴我,你在想什么”這樣的話;5)當主持人不知道參與者在想什么的時候,就應該提醒參與者可用性測試的原則,鼓勵參與者進行“發聲思維法”,將所想的大聲講出來;6)主持人對參與者有道德責任。應該對參與者的表情明察秋毫,當發現參與者表現出沮喪或者失落的時候,應該進行干預和安撫;7)確保參與者能完成高優先級的任務,并且任務的取舍也應該按照優先級排列;8)保持中立,向參與者傳達你將公平公正的聽取他的意見這一信息;9)不要嘗試引導或者影響(有意識或者下意識)參與者。
測試結束后的要點
1)在每個可用性測試之后,都應該整理出一頁發現列表(finding list);2)發現列表不是指又臭又長的報告,這一列表中包括了通過測試,發現了哪些問題以及參與者對這些問題的評價;3)召集參與了可用性測試的相關人員,對他們在觀看中發現的問題做一個列表排序,排出問題的優先級,下一步就是著手改造。4)按照優先級排列這些問題;5)永遠都嘗試解決最嚴重的問題;6)“Less is more”,少即是多。不要對和問題相關的設計進行顛覆式的修改,而應該嘗試去微調和優化這些設計;不要為了去解決問題而添加新的功能,保持設計的簡潔。
經過四輪共耗時30個小時的簡易可用性測試,我們一共發現了200個左右的問題,其中最高優先級的占了30%左右。簡易可用性測試的成本低,速度快,卻能發現重大問題,提供非常有幫助的數據,值得在中小型互聯網公司推廣。
[1]Wikipedia.Usability testing.http://en.wikipedia.org/wiki/Usability_testing.
[2]Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, Steve Krug,2009.
[3]Collecting Data from Users.http://usability.gov/method/data_collection. html.
[4]Rosenfeld L, Morville P.Information Architecture for World Wide Web.CA: O'Reilly&Associates, Ins.,2002.
[5]Nigel Bevan.Measuring Usability as Quality of Use[J].Journal of Software Quality,1995(4):115-130.