【使用者研究】【實戰】——“得到”APP 可用性測試

【使用者研究】【實戰】——“得到”APP 可用性測試

得到APP簡介

得到APP是由羅輯思維團隊推出的主打付費知識音訊服務的APP,通過訂閱專欄、音訊課程、拆書解讀等方式為網友每天提供有價值感的知識內容,主要模組有「每天聽本書」、「訂閱專欄」、「大師課」、「精品課」和「電子書」等。

補充說明

在設計師完成某個頁面後,設計師和維護人員通常需要對介面進行可用性的檢查和評估。在設計週期初期使用者量不多的時候,常用的評估方法主要有啟發式評估可用性測試

啟發式評估即找幾個評審員根據一些可用性理論和以往的設計、使用經驗來判斷產品介面的可用性問題。可用性測試即讓使用者通過模擬現實生活中的使用情境來使用產品,從而設計師可以觀察到使用者使用時的操作績效和表現出的感受和體驗。一般而言,使用者操作績效可以通過三個指標來進行評估:操作完成率完成時間完成路徑。本次對得到APP進行可用性評估採用的是可用性測試的方法。可用性測試除了以上的客觀操作指標外,還通過出聲思維的方式採集使用者認知過程作為補充。

出聲思維即讓被試在測試的時候言語報告其思考,使得思維過程外顯化,能夠被直接觀察。可用性測試中的出聲思維要求被試在完成任務的同時以口頭言語的形式報告出任務操作情況,可用性測試專家通過對被試報告內容的分析,可以獲知被測系統中存在的問題、哪些部分常為被試所忽視或誤解以及被試對使用系統的看法等。

可用性測試

1. 任務設計

在進行任務設計前,首先梳理了得到APP的產品結構,如上圖所示。由於時間和技術條件有限,本次只對該APP的核心模組進行測試,如「每天聽本書」、「訂閱專欄」、「電子書」等,主要測試各模組下的內容搜尋/查詢內容的可用性使用效率滿意度。一共設計了13項任務,具體任務清單不在這裡公開。任務設計遵循以下三個原則:

  1. 從使用者的角度出發:使用者介面最重要的作用是支援使用者達到自己的目的,而任務就是使用者的目的,所以要根據使用者的目的設計恰當的任務;
  2. 明確的起點和任務目標:使用者測試中最重要的是”使用者是否可以完成任務”,因此要明確定義目標。有時候任務相同,如果目標不同,測試目的也不大相同。同樣,也要注意定義任務起點;
  3. 劇本化:儘可能自然地引入測試任務。實際使用時,使用者會有自己的理由和目的,但測試中不是這樣的,如果沒有動機,使用者就不會主動行動,而是等待指示,因此要追加一些假設的情境,把任務潤色成故事,使用者就可以通過自己以往的經歷,帶著生活實感,更主動地使用產品。

2. 測試流程

整個測試一共包含3個流程,依次是事前訪談、任務測試、事後訪談。我們對整個流程設計了執行指南,執行指南詳見附錄B。

事前訪談

事前訪談主要包括:1) 取得錄影/錄音許可,簽訂資訊保密協議;2) 被試資訊的採集,主要包括個人基本資訊、相關APP的使用習慣、感興趣的知識領域等,我們會根據相關資訊,調整任務的情境;3) 對被試進行事前說明,並進行出聲思維的訓練。詳情見附錄B。

任務測試

事前訪談結束後,我們根據事前準備好的執行指南讓被試進行任務測試。在整個任務測試過程中,使用者被試是主角,我們則是隱藏的觀察者,我們的任務是正確傳達任務指示,讓被試瞭解任務目的,並在一個任務結束後引導被試進入下一個任務,遵循“不提問、不回答、不注視”的原則,對被試提出的要求只能是“請認真完成任務”,在原則上不給使用者任何幫助,對使用者的操作不肯定也不否定,確保被試自由發揮,獨立完成任務。在所有測試任務結束時,我們讓被試填寫SUS可用性滿意度問卷。

  • 測試裝置:為了保證使用者在測試過程中不會因為對測試裝置的不適應而影響任務進行,在裝置有限的條件下,我們採用被試自己的手機作為測試裝置 (測試前下載好得到APP並進行了註冊)。
  • 測試道具:任務資訊卡(主試在給被試傳達任務指示的同時提供任務資訊卡,卡片上有任務背景、任務目標等資訊說明,以保證在測試進行時,被試不會忘記當下的任務目標)
  • 資料採集:1) 主試的觀察記錄,為事後訪談提供參考資訊;2) 手機錄屏、錄音,供事後分析使用。(如果條件允許,推薦使用行動式眼動儀

事後訪談

在實際操作中,由於各種各樣的原因,被試往往未能發言說出思考的內容,我們並不能獲得完整的資訊,這些遺漏的資訊將在事後訪談進行補充。這裡採用回顧法(回顧法 Retrospective Method) 對被試進行事後訪談,訪談的主要內容包括:

  1. 測試過程中被試未能發聲的問題
  2. 測試過程中遇到的困難細節
  3. 其他疑問以及對產品的建議

3. 測試結果

被試基本資訊

從XX大學招募了5名被試,包括3個iOS使用者,2個Android使用者,4女1男,年齡都在18~24歲之間,可支配收入大概都是2k左右。其中:

  • 4人未曾使用過得到APP,主要使用的相關APP有喜馬拉雅,知乎live等
  • 在功能使用方面,主要是聽音訊。包括聽故事、小說,TED、相聲,或者其他知識音訊等;使用頻率方面,聽的時候每週大約4~5次,都是高頻使用者。1人是得到APP的忠實使用者,大概至少2天聽1次;他們感興趣的知識內容包括科學科普,經濟學,AI,歷史,生命科學等等
  • 所有使用者都對知識付費有所瞭解

任務完成概況

統計了每一個被試的任務完成情況,主要包括1) 是否完成任務設定的目標;2) 每一個任務起點到任務目標的平均跳轉次數;3)平均耗時等,具體結果不在這裡公開

問題統計

根據被試的任務完成情況以及事後訪談所反饋的資訊,整理了這5個被試在測試過程中遇到的問題(這裡不公開),為了保證準確性,我儘量還原了被試對問題的描述。

隨後我把被試反饋的問題按性質分成了三類:可用性問題、效率問題、滿意度問題。結合這些問題發生的頻數,我對這些問題進行了影響度分析 (見下表),問題影響度主要反映了問題的嚴重程度和待解決的優先順序,其中:可用性問題>效率問題>滿意度問題;高頻率>中等頻率>低頻率

發生頻數

可用性問題

效率問題

滿意度問題

(3-5)

  1. 不能分類查詢電子書;
  2. 不能在電子書專區搜尋內容;
  1. “收藏”的入口太難找
  2. 課程目錄的呈現不明顯,容易被忽略

暫無

(2)

  1. 不能通過課程表直接連結到內容;
  2. 缺失幫助進行購買決策的資訊(銷量、評價等);
  1. 定時關閉的使用不符合常規習慣;
  2. 收藏功能呈現有歧義(以為是點贊),並且沒有操作反饋;
  3. 訂閱專欄內的指定內容無法便捷地找到(月份篩選功能很雞肋);
  1. 不能直接購買,必須先往賬戶充值;
  2. 不能自定義充值金額;
  3. 不能自定義定時關閉的時間;

(1)

聽書/電子書不能試聽/讀;

  1. 訂閱專欄的留言不能摺疊,浪費時間;
  2. 筆記游標不靈敏;
  1. 純音訊介面和文稿介面不能通過左右滑動來切換(音樂APP使用者);
  2. 一次訂閱一年,價格很貴,希望能夠短期訂閱;

注:得到APP的核心需求是提供優質的內容,但這裡只關注並解決互動設計相關的問題 (排除戰略和技術層面的問題),因此在後續的解決方案中,只篩選出相關問題進行解決。

可用性滿意度

整體滿意度評價使用了SUS量表 (見下表),內容如下:最後計分得到59.2,根據量表評分經驗(60分為臨界),由此可見使用者對得到APP的可用性不太滿意。

SUS可用性滿意度量表:

題目及序號

1=非常不同意,5=非常同意

1.我願意使用得到

2.6

2.我發現使用得到很複雜

2.2

3.我認為使用得到很容易

3.0

4.我需要專業人員的幫助才能使用得到

2.0

5.我發現得到的各項功能都能很好的整合在一起

3.0

6.我認為得到的使用過程中存在大量與我的想法不一致

2.8

7.我認為大部分人都能很快學會使用得到

3.6

8.我認為得到使用起來比較麻煩

2.4

9.使用得到的過程中我很有信心

4.0

10.使用得到時我需要大量學習

2.2

4. 問題分析

根據任務完成一覽表,可知被試沒有達標的任務有1-1、3-1、6-2、7-2、8-1、11-1。這裡只對沒有完成任務的可能原因進行了分析。

任務1-1

  • 任務描述:你作為新使用者,對“得到APP”還不太瞭解,APP裡的很多內容都需要付費,所以你想先找到免費的內容體驗一下,請你現在隨意找一個免費的內容聽一聽。
  • 分析:該問題有一定的偶然性。得到APP的首頁排版有2種,不同時間段隨機出現。如下圖所示,未能完成任務的被試看見的是左邊版本,它見到的第一個欄目是收費專案,且費用資訊寫在螢幕右側,導致使用者回拉的時候目光更多的注視在右側搜尋“免費”或者“¥0.00”等字樣,此時她形成了價格在右邊的認知,未能發現免費專欄的資訊。

                                                                                          得到APP首頁

任務3-1

  • 任務描述:你發現得到APP裡還推薦了一些電子書,你打算挑一本XX相關的電子書看看,並決定是否購買 (你的預算充足)。
  • 分析:一般而言,使用者找書的時候,會帶有一定的目的性,可能是某一類書或者某幾類書。因此在執行此任務時使用者實際是在進行視覺搜尋。而在這個介面中 (見下圖),沒有任何的分類幫助使用者進行篩選,因此在找書時,使用者感知到的資訊噪聲過多,使用者更容易知覺成“不是目標類目的書籍”;按照訊號檢測論,使用者更容易誤判資訊為“不是目標書籍”而略過,使用者找到目標書籍所需的時間過長,並且這個頁面沒有提供搜尋功能,當使用者經過幾次嘗試沒有找到書也沒有其他線索時,會感到挫敗。

                                                                                  得到APP電子書模組介面

任務6-2

  • 任務描述:進入“劉潤5分鐘商學院 · 實戰”專欄介面,檢視該訂閱專欄的內容目錄(課表),瞭解一下專欄內容的具體組成。
  • 分析:使用者對於課程目錄的認知,應該在課程介紹的頁面。目前的設計中,課程目錄作為課程內容的一部分,在首期內容“發刊詞”內 (見下圖)。必須要付費訂閱專欄之後才能看到。所以使用者目前只能在專欄首頁只能找到類似於課程大綱這樣的東西。而課程目錄又是倒序排列,沒有對目錄進行置頂,使用者進入時不一定能知覺到有目錄這個內容。

                                                                                     訂閱專欄的課程表

任務7-2/8-1

  • 任務描述:你很喜歡現在聽的這則內容,想收藏這則音訊&現在你想回顧一下剛才的收藏的音訊。
  • 分析:7-2和8-1分別是收藏和檢視收藏任務。收藏功能在其他APP/web中所用的符號是☆。在得到APP中,這個符號是♡,且這個符號旁邊有數字,這與一般人知覺的“收藏”含義不符。實際調查中發現,使用者更傾向於知覺這個符號為“喜歡”或者“點贊”。互動細節方面,使用者在點選這個按鈕後,除了圖示變色告知使用者點選生效外,沒有告知使用者到底發生了什麼,沒有起到一個防止錯誤作用。資訊結構方面,在其他APP中,收藏常與“我的”放在一起,在這個APP中收藏放在了比較深,且與收藏相關度不高的“我的筆記”頁面的角落中。使用者很難知覺到收藏到底在哪裡,從而反過來更不確定♡是不是收藏。

任務11-1

  • 任務描述:現在是晚上11:30,你現在正在聽你剛剛購買的書,你已經開始困了,怕自己聽睡著了忘記關音訊,想讓當前音訊在合適的時間關閉。
  • 分析:任務中的問題與前面幾個類似,即資訊結構與使用者認知不符。按照類似的音樂播放器的設計邏輯,定時功能在“我的”裡面。在得到APP中,播放音訊不需要進入播放器頁面內部,只需要找到合適的收聽內容,然後點選播放按鈕即可。使用者不太熟悉播放器頁面具體有哪些功能。而得到APP的定時功能又只能進入播放器才能看見,所以使用者很難知覺到定時功能在哪裡。

                                                                                       音訊播放介面

其他問題(可以完成但不是很理想):主要有兩類,一類是搜尋功能的入口位置,另一類是個性化設定。資訊搜尋過程中,當使用者進行幾次搜尋後沒有找到相關資訊,會知覺到資訊噪聲過多,進而尋求篩選/搜尋功能。得到APP涉及到很多個內容展示列表,比如電子書列表,專欄目錄等等。但這些列表並不是每個都具備搜尋功能,可以說不具備內部功能的一致性。個性化設定方面,定時功能也不太符合使用者的具體使用習慣。

 

改進方案及再測試

對相關問題進行分析後,我們對這些問題進行了改進方案的設計,並進行了在測試對改進方案進行檢驗。

1. 改進方案設計

任務1-1:屬於商業戰略問題,不在我們解決的範疇。

針對任務3-1:在“電子書”介面內增加分類和搜尋,與“聽書”和“商城”中的檢索方式保持一致。減少資訊噪聲比率,使使用者找書過程中更有信心,效率更高。

                                                                         改進後的電子書瀏覽介面

針對6-2:把包含了課程表資訊的“發刊詞”進行置頂。

                                                                                改進後的訂閱專欄內容介面

針對任務7-2/8-1:a) 增加使用者互動反饋——使用者點選“❤”後,彈出“已收藏”字樣,讓使用者知道這到底是什麼;b) 在“我的”中新增“我的收藏”按鈕,圖示與愛心符號一致,使資訊結構符合使用者認知。

                                                                     改進後的收藏反饋介面和“我的”介面

針對任務11-1中出現的問題,在事後評估時發現,這是與音樂播放器不同的兩種設計方式,是否需要修改有待進一步研究才能得知。

2. 再測試

根據改進方案,我使用Axure製作了改版原型 (用瀏覽器開啟可進行操作),讓另外的5名被試進行了二次測試,流程和原來一樣,但只針對那幾個問題任務進行了測試。

測試結果在這裡不公開,最後的結論書:任務完成比率都達到了100%,平均跳轉次數也有所降低,可用性得到提高 → 解決方案有效。

總結

雖然最終提出了一定程度上可行的改進方案,但在整個可用性測試環節中,這裡仍存在以下幾個問題:

  1. 由於條件所限,測試裝置是被試自己的手機,雖然他們的手機都是同樣的尺寸, IOS系統和Android系統的互動體統是有細微差別的(比如在Android手機上,可以通過點觸home鍵返回到上一級介面;得到APP在Android系統中是沒有“回到頂部”的按鈕的),這些差別會導致測試結果存在個體差異;
  2. 被試本身對知識付費雖然有興趣,但對得到APP或者其提供的知識內容不太瞭解,故在滿意度方面或有一定程度上的偏低;
  3. 任務施測過程中,使用者會下意識的瀏覽其他頁面,並自動完成了其他任務,這導致任務難度的評估不夠準確;
  4. 被試的出聲思維能力層次不齊,真正出生表達的想法不一定符合實際,也存在旁觀者偏差。
  5. 收集資料方面,由於裝置限制等因素,這裡使用了手機錄屏 錄音的方式進行,可以參考的資訊有限,並且準確性有待提高。雖然在測試過程中操作了任務的起點,但在資料統計時很難知道被試在操作過程中真正的起點,所以任務耗時只是一個估計的數值;此外由於在測試時,其中一個被試不願意開啟手機的“勿擾”模式,導致在來電時錄屏中斷,部分資料丟失;今後的測試可以加入眼動儀,能得到更多資訊。

 

參考文獻

  1. Brooke J. SUS: A quickdirty usability scale[J]. Usability Evaluation in Industry, 1996, 189.
  2. 樽本徹也. 使用者體驗與可用性測試[M]. 人民郵電出版社, 2015.
  3. 約瑟夫·杜瑪斯.可用性測試——互動理論與實踐[M].國防工業出版社,2016.