Guerrilla 可用性測試:7 步 DIY 屬于你的可用性測試方法
你不需要一個完整的產品來驗證用戶反饋的價值。如果你等著在產品面世后才開始測試,那么為時已晚。
在用戶體驗和產品開發領域,調研和規劃決對產品來說,起了決定的作用。
忽視它們,將讓你以及你的團隊蒙受巨大的損失,這包括高用戶流失、客戶服務需求(和成本)增加、開發成本和時間增加,總而言之——完全浪費資源。
可是,當最后期限臨近以及預算過低的時候,我們能做什么呢?
你可以使用 Guerrilla 可用性測試,這是一種精益敏捷且節省成本的測試方法。
我們將用簡單的 7 個步驟向你介紹如何構建 Guerrilla 可用性測試,并獲得高效的回報。
不過,首先讓我們回答 Guerrilla 可用性測試相關的三個最常見的問題:
- Guerrilla 可用性測試如何起作用?
- 從哪去找合適的測試志愿者?
- 什么時候開始測試?
Guerrilla 可用性測試如何起作用?
Guerrilla 可用性測試的主要目的是快速發現問題和快速解決問題。
Guerrilla 可用性測試容易做,你不必擔心下面這些事:
- 昂貴的記錄設備
- 研究實驗室
- 志愿者參與(差旅費,安排,計劃和結束等)
- 書面工作和管理
- 招募志愿者,他們的人口統計資料與目標受眾相匹配
適合 Guerrilla 可用性測試的人才是我們所需要的。
這使得 Guerrilla 可用性測試非常精簡和敏捷。你只需要幾個小時便可發現問題。
并且測試過程非常的簡短,大約 15 分鐘左右:
- 你接近一個人
- 詢問他們是否想回答關于產品的幾個問題
- 給他們一些任務
- 觀察他們
- 詢問他們
- 這就完成了一次測試
因為在測試過程中你會收集定性數據,你只需要 3-5 個人便可發現關于產品的最大可用性問題。
發現問題后就立即解決,解決的問題將在下一輪測試中得到驗證。
對于認可可用性測試價值的相關利益方而言,Guerrilla 研究是完美的啟動方式。
我們容易接受用幾個小時并且幾乎無需花銷的 Guerrilla 可用性測試,而不是需要數月規劃和執行才能完成的測試。特別是當我們知道團隊所有的時間不多,以及預算不足的時候。
有發現總比沒有發現好。即便是你的研究快速簡單,也是非常值得的,也比沒有好。
從哪找合適的測試志愿者?
與傳統的可用性測試相比,無需招募 Guerrilla 可用性測試的志愿者,因為他們就在你身邊。
一種較容易的方式是,把你的親朋好友當作志愿者——他們無法逃脫,畢竟你知道他們住在哪。
值得注意的是,你的親朋好友非常了解你和你的產品,很難從他們那得到真實的“產品初體驗”;況且,你老媽和姨媽由于特別在乎你的感受而表現的過于友好…
因此,比較好的方式是采用對你和你產品不了解的人作為志愿者。這些人通常在咖啡廳或者商場。
專業提醒:如果你的原型和網站需要在線才能使用,確定選一個有穩定 Wi-Fi 的地方。哦,別忘了電也要充足,你也不想在測試的時候沒電了吧。
什么時候開始測試?
我們為我們的業務做了數百次的可用性測試,并且還沒有遇到過一次一無所獲的時候。
這就是你要盡早并且經常測試的原因,畢竟解決問題的成本變得越來越高,你的產品也會越來越好。
牢記:你不需要一個完整的產品來驗證用戶反饋的價值。如果你等著在產品面世后才開始測試,那么為時已晚。
那么,讓我們開始吧!
第一步:設計任務列表
第二步:定任務優先級
第三步:將任務設置在場景中
第四步:開始測試
第五步:發現問題
第六步:解決問題
第七步:再次測試、驗證,形成常態
(文章介紹步驟于圖片內容略有不同)
第一步:設計任務列表
首先,要寫下人們在你產品上完成的所有任務的清單。
如果人們在你的產品中買東西,在任務清單中就應該有一個要求測試者購買產品的任務;如果你想人們創建賬戶,也應該有一個這樣的任務;等等。
例如,Facebook 的任務可能是:
- 滾動時間線
- 更新狀態
- 發送私信
- 上傳照片
- 添加好友
- 修改密碼
你自己試著寫寫看,思考所有人們在你的產品中做的重要的事,并寫下一個簡短的任務清單。不過,不要在細節上浪費太多時間,僅僅是把人物寫下來。剩下的,我們會在下一步中具體介紹。
第二步:定任務優先級并確定測試項
當你有一個任務列表之后,是時候通過給 1-3 的分值來給所有的任務項拍優先級了,這些分值表示的是任務被使用的頻率。
例如:
- 3 分表示用戶經常使用該任務(高頻)
- 2 分表示偶爾使用
- 1 分表示僅一次(類似在電商產品上退回產品)
根據上面的打分,剛才我們列出的 Facebook 的打分是這樣的:
- 滾動時間線 3 分
- 更新狀態 2 分
- 發送私信 1 分
- 上傳照片 2 分
- 添加好友 1 分
- 修改密碼 1 分
不要過多的關注這個排行,通過這個排行找到用戶最常用的任務就可以了。
為什么?
因為你一次不能把所有的測試項都做了(不在 Guerrilla 可用性測試中全部做完)。如果你把第一次測試的關注點放在發現并且解決最重要的部分,你會得到最高的投入產出比。
那么,我們就得到了 3 個最重要的測試項:
- 滾動時間線
- 更新狀態
- 上傳照片
重申一次,Guerrilla 可用性測試是關于快速獲得結果并立即采取行動的測試方法。
僅選 3 個最重要的測試項并開始執行。剩下的,稍后測試。
第三步:將任務設置在場景中
現在,將測試項放到用戶能夠閱讀、理解、遵循的場景中。
專業提醒:只要你的場景合適,你的測試才能起作用。好的場景能夠幫助你測試,那就和目標受眾參與測試一樣。
這里有幾個設計場景的規則:
- 不要在場景中提供線索。你必須對你的場景進行說明,以便清楚易懂,但是你必須使用通俗的語言來解釋,而不是艱深晦澀的語言。否則,你就會把測試變成了文字游戲。
- 讓你的場景容易遵循。寫下你的說話方式,盡可能避免科學或學術語言。與朋友和同事預先測試場景,確保易于理解,人們可以毫不猶豫地遵循。
- 去掉任何不起作用的細節。場景為用戶提供了上下文(“你是…”,“你想…”),并為他們提供了所有必要的信息(例如用于測試的賬號和密碼)。其他一切都是不必要的,你應該盡可能縮短你的場景。
讓我們用 3 個任務項試一下:
(1)滾動時間線
我們不能僅告訴用戶在沒有任何動機或目標的情況下“滾動時間線”。我們可以向人們提供一個理由去做,而不是描述要做什么。
不好:滾動頁面查看新帖子。
這只會讓你的用戶像機器人一樣執行任務。沒有任何動機,他們只會翻閱頁面,你不會了解到任何關于如何提高可用性的東西。
一般:看看這個頁面,找出它的全部內容。
這至少是開放的,可以讓人們更自然地瀏覽頁面。只要告訴他們看看這個頁面,他們很有可能會滾動瀏覽這些帖子來了解它的全部內容。
好的:想象一下,這是你今天第一次查看 Facebook。現在試著去找到今天發布的第一篇文章。
最后,這是有效的,因為它為用戶提供了一個真正的目標。與其僅僅告訴他們該做什么(不好的)或希望他們會這么做(一般),你可以給他們一些特定的事情來做,這會自然而然地激勵他們使用你的產品(好的)。
(2)更新狀態
對于下一個任務,您需要激勵人們輸入實際數據(而不是滾動瀏覽)。讓我們看看不同的方式:
不好:寫內容并發布。
這給如何使用該網站提供了太多線索。人們只需查找“狀態更新”,也可以選擇“發布到個人頁面”的按鈕。再有,這種情況并沒有提供任何動機或原因,為什么你想要更新狀態。
一般:通過更新讓你的朋友知道你在做什么。
這解釋了為什么要更新狀態。但它還不好。而且“更新你的狀態”這個事實仍然存在,這使得它再次成為一個簡單的尋找文字的游戲。
好的:找到一種方法讓你的朋友知道你在做什么,并告訴他們你正在測試一個產品。
這非常有效,因為它避免提供關于如何使用的任何線索。再有,它為用戶提供了一個特定的目標(找到一種讓朋友知道的方法),甚至為他們提供了可以使用的信息。
這有助于減少在測試期間考慮應填寫什么類型的數據而導致的心理努力。
(3)上傳照片
這一個有點棘手,因為我們一定要避免“上傳”和“照片”字樣(因為它們在產品界面上),但我們又不得不告訴測試者上傳照片……
不好:找到上傳照片的方法。
這太明顯,我什么都不想說……
一般:找到一種與朋友分享照片的方式。
這個其實很不錯。雖然動機部分仍然讓人摸不著頭腦,但與朋友分享圖片的想法是一種很好的方式,上傳圖片的行為定義對大多數人都是有意義的。
好的:昨晚你參加了一個派對,拍了一些滑稽的照片,現在你正在尋找一種方式分享,并且讓你的朋友也能看到它們。
這提供了所有必要的上下文,來了解用戶嘗試實現的情況和目標。
注意每個細節是如何有意義的,并有助于整體理解。就像如果這些圖片很滑稽,這會導致一些用戶特別注意隱私設置(在與朋友聚會的前提下,“滑稽”一詞相關的上下文內容,并不一定是大多數人希望公開的東西)。
第四步:組合 3 個場景
好!剛剛我們只是將最重要的任務項轉化為場景,現在是時候將它們組合起來:
- 想象一下,這是你今天第一次查看 Facebook?,F在試著去找到今天發布的第一篇文章。
- 找到一種方法讓你的朋友知道你在做什么,并告訴他們你正在測試一個產品。
- 昨晚你參加了一個派對,拍了一些滑稽的照片,現在你正在尋找一種方式分享,并且讓你的朋友也能看到它們。
好了,這很簡單吧。現在你只需要開始測試。但首先閱讀并學習如何去做第五步。
第五步:開始測試
正如開頭提到的,Guerrilla 可用性測試的秘訣在于接近人,并要求他們測試你的網站、應用或原型。
無需關心測試者,也不需要擔心如何記錄會話,因此不需要特別記錄或其他任何東西,便可開始開始測試。
只要走到某人面前,問是否可以耽誤他幾分鐘的時間。為了獲得更好的效果,甚至可以提供一點小禮物感謝他們的參與,如免費咖啡或松餅。
一旦你足夠親切地接近他們,你也會找到其他人,并在每次測試時,都會變得越來越好。
(1)如何找到人參加
當你面對測試者的時候,你要怎么說話:
“嗨!我們正在做一個網站(應用、原型,或是其他),并且想看看它是否符合預期。請問能占用您幾分鐘時間,和我們一起看看這個網站么?
你愿意幫我們完成這些測試么?在你回答之前,你絕對不會做錯什么的。另外,你可以免費享用咖啡、松餅,謝謝!“
(2)說明測試
由于大多數人不知道可用性測試是什么,所以在給出這個場景之前,通常要做一些解釋:
“你必須知道的第一件事是:我們正在測試網站,而不是你。 所以你不必擔心犯任何錯誤。我們希望看到你指出我們的錯誤。
當使用該網站時,我們希望你大膽地思考。只要說出你在看什么,它如何影響你,在每次互動之后你期望發生什么,你想要完成什么,等等。
請不要在意我們的感受。我們希望改進網站,并且需要聽取你的真誠的反饋?!?/p>
這是有趣的一部分。只要給他們你的場景,退后并觀察他們如何使用你的網站、應用或原型。并且記得閉嘴。
(3)記得保持沉默
在這種情況下一樣,你不想給出任何有關網站使用方式的線索。
你不想引導你的用戶。你想看看他們是如何找出自己的東西;或者他們怎么找不到,這可以幫助你了解更多!
避免引導用戶的最好方法是:在測試過程中保持沉默。
在現實生活中,當他們使用你的產品時,你不會坐在他們身邊。你當然希望測試會盡可能真實。
你的參與者當然會有問題,而且當你坐在他們旁邊時,自然會指引他們走向你。
每當他們問你什么時,為了避免任何不好的感覺,只要這樣告訴他們就可以了:
“這是個好問題。我現在還不想回答你,因為我們感興趣的是當沒有人坐在他們身邊時,你如何使用這個網站。不過,我會在測試后給你答復?,F在你有這個問題了,如果我不在這里,并且你正在使用這個網站的話,你會怎么做?“
你會找到自己的方式,來處理測試過程中出現的問題和其他情況。
唯一應該談的是提醒用戶大膽地思考。他們經常保持沉默,特別是在試圖找出某些事情時,那就是當你必須給他們一點點推動時。
請記住,目標是讓你的用戶推動大部分的對話。理想情況下是 100% 的時間都是。
(4)討論問題
一旦測試者完成了這個場景并且完成了所有的任務,是時候定位測試過程中出現的問題,并且可能的話,你自己也要提出一些后續問題。
如果碰巧遇到目標受眾參與測試,你可能還想將其轉換為客戶訪談,并詢問他們是否真的會使用產品。
但由于這不是可用性測試的一部分,我們繼續下一步。
第六步:發現問題
盡量避免在測試過程中發現問題。
恩,那就對了。因為如果你坐在測試者的旁邊,并且你一直在寫東西,你絕對搞砸了這次體驗。
人們會感到壓力,想知道你在寫什么,或好或壞,或者他們做錯了什么…
測試期間,你應該只需關注觀察用戶并試圖理解他們的行為、他們的語言以及隱藏在這些背后的細微差別。
是的,用戶在大膽地思考,但是人們很難將他們的潛意識思想轉化為意識以及他們想要表達的意思。
這就是為什么你要不斷問自己:“他們表達的想法背后還有其他意思嗎?”
你的頭腦必須被設定為觀察(而不是記錄),并且你會看到你能夠記住所有重要的事。即便你忘了一些東西,你還會做其他測試(就如你在后面的步驟中看到的),如果這是一個真正的問題,它會再次出現。
那么,如何發現問題呢?
方法1:列出前 3 個可用性測試問題
發現問題最明顯的方法是簡單列出測試中確定的前 3 個可用性問題:
沒必要記下來你發現的所有事情。Guerrilla 可用性測試是關于發現和解決主要問題的測試,而不是了解困擾用戶的每一個細節的測試。
方法2:發現任務完成
記錄發現的更復雜的方式是了解每個參與者的任務完成情況。
如果你需要提供給客戶和其他利益相關者一些信息,這一點特別有用。
你可以使用以下方式:
- 如果用戶可以快速且毫不費力地執行任務,將其標記為 3。
- 如果用戶可以執行該任務但存在一些問題,將其標記為 2。
- 如果用戶無法執行任務,將其標記為1。
結果可能是這樣的:
我們在 Simplease 的項目中使用過這個表格。
第七步:解決問題
正如本文開頭提到的那樣,解決問題可能很貴。特別是如果問題影響正在運行的應用和網站的時候。
這就是為什么在編寫代碼之前盡早通過設計原型并進行測試,盡可能解決主要問題的方法是十分明智的。
但是如果已經過了這個原型設計階段,并且通過 Guerrilla 測試發現了問題,公司會花費數百個開發時間和數千美元才能解決問題么?(囧!感覺這個在國內,那都不是事啊~)
(1)優先解決最大的問題
如果你的工作是吃掉一只青蛙,那你最好早上就做它。如果你的工作是吃掉兩吃青蛙,那你最好先吃掉那只大的?!?馬克·吐溫
細心的讀者會注意到一種模式。首先,我們只測試最重要的任務。然后我們只寫下最重要的問題?,F在我們先解決最大的問題。我們很快就做到了。
(2)快速解決問題
在解決問題時,盡量做到最少?!?斯蒂夫·克魯格
不斷地問自己,你做出什么最小、最簡單的變化,可能會讓用戶避免遇到問題。
對于直播網站尤其如此,但許多人反對這一想法。
在《妙手回春:網站可用性測試及優化指南》一書中,史蒂夫·克魯格指出,你不必為問題尋找永久的解決方案。只需找到一個容易實現的快速解決方法,就可能解決問題,并進行更多的測試以確定這個方法是否已經可行。
(3)微調整,不要推倒重來
在完成了一些可用性測試并開始考慮如何解決問題之后,總是很容易做遠超實際的調整。
遲早,你會發現就想要重新設計鄭哥網站了。
這種推倒重來的偏見有很多原因,很容易理解為什么很多人喜歡重新開始,而不是僅僅實施一個快速解決方案。
我們自己有罪,但希望這份清單(依然來自斯蒂夫·克魯格)能夠幫助我們記住為什么調整比重新設計更好:
- 調整成本更低
- 調整需要較少的工作量
- 可以盡早做出小的改變
- 小的變化更可能發生
- 大多數人不喜歡變化,所以重新設計會讓他們感到煩惱
- 調整不會破壞生活,不會分裂家庭,不會破壞職業生涯
- 重新設計意味著在頻繁的會議,不停的溝通。不說了吧
- 重新設計意味著立即做出很多改變,者伴隨著復雜性和風險
- 如果做出更大的改變,在這個過程中更有可能破壞工作正常的事情
如果你仍然不相信快速解決以及它比推倒重來更好,那么繼續進行 Guerrilla 可用性測試的下一步(也是最后一步)——再次測試并形成常態。
之后所有事情都會有意義…
(4)再次測試并形成常態
如果持續進行,可用性測試效果最佳。
不必花費過多的時間和金錢來進行復雜的可用性研究,以便推倒重來,你可以實施快速解決問題。
訣竅是繼續測試以確保解決方案能夠正常工作。
(5)測試頻率
關于在可用性測試中需要多少用戶,有一些有趣的討論。
一個流行的經驗方法是:與 5 個用戶一起測試,以發現任何應用程序中最嚴重的問題。但一如既往,這取決于…
如果一個用戶在 30 秒后遇到了了一個重要的可用性錯誤,其他四個測試就不需要了。
最后,這不是高深的事。有時候這很明顯。即使只針對一個用戶進行測試。
唯一重要的是定期重新測試(如果可能的話,每周一次)。
通過這種方式,可以查看調整是否真正解決了問題,并且確保發現可能由更改導致的任何新問題。
(6)讓測試成為工作流程的一環
Guerrilla 測試往往比傳統的可用性測試好幾倍原因是,你可以負擔得起定期做這件事;當然,我不僅僅在談論金錢。
Guerrilla 隊可用性測試既快速又簡單、價格便宜,它的效果非凡,沒有理由不這樣做。
Guerrilla 可用性測試有很多種形式。在你使用的時候制定你自己的方法:邊做邊學。
相關閱讀
原文作者:Markus Pirker
原文地址:https://userbrain.net/blog/7-step-guide-guerrilla-usability-testing-diy-usability-testing-method
#專欄作家#
鄭幾塊,人人都是產品經理專欄作家,前新浪微博產品經理。
本文系作者@鄭幾塊 獨家翻譯授權,未經本站許可,不得轉載
題圖來自 Pixabay,基于 CC0 協議
請問測試的時候用戶無法執行一個任務,但是不執行會影響接下來的測試,那應該怎么提示用戶比較好呢?
建議不用強硬的引導方式,可以用另一個任務解釋說明當前的問題和狀況。如果用戶還是不能理解的話,你可以中斷測試,問一下為什么會出現這個問題。如果多個用戶在這個環節都出現問題,很有可能是產品流程除了問題。那樣你就獲得了比較好的反饋,為后續改進產品有了一定的積累。
嗯嗯,謝謝 ??