Execute a User Testing

Background

這是一個internal app revamp design的project。但是設計以及development是outsource給vendor做。

其實vendor的design team已經算是一個很成熟的團隊，根據timeline給出質量不錯的deliverables。但是由於他們接觸不到end user，溝通也只是跟stakeholder開會，未能完全知道user會怎樣用。當他們propose一些他們認為在ux上比較好的idea的時候，stakeholder卻覺得不需要；當stakeholder認為不需要的東西，他們也覺得不make sense。

在這個情況下，就出現了communication gap。而我在其中的角色應該是communication bridge。所以這一次，我便嘗試跟vendor design team合作，用他們做的prototype（他們認為userflow比較有爭議性的幾個scenario）來跟user做一次user testing，通過這個test來得到一些qualitative result

Work with Vendor Designer

Goal

1. Get to know how end users use the app
2. Get to know the feedbacks from them about each version of each flow

Preparation

(1) 30mins Briefing from Vendor

由於這個prototype是vendor design team做的，他們希望找到更好ux的userflow，因此有3個flow要做測試，每個flow有2個version。看看哪一個version更好，或者有什麼改進的地方。

在會議上，他們除了給我demo一次prototype，還給我講述他們想要的結果——選出更好的版本或者給出insight / testing report或者在設計上提出一些可行的意見；他們想要了解的問題，例如他們想知道在某一頁上面的button，user是否有留意到其作用；還有recommended device。

當問到應該用什麼形式與user做testing，最ideal的方法是每個user都用同一個device，然後我在旁邊引導他們完成一些task，可以達到最好的效果。但是PM concern的問題是，不知道end user有沒有時間或者有沒有場地做這樣的事情，如果用teams sharing screen可不可以。在這一點上，我跟design team卻達到共識，還是認為in-person moderated research會更加有效以及更加有效率。因此，我也請PM幫忙聯繫一下user，讓我跟user介紹一下我們的methodology再約時間做testing（萬分感謝🙏）

隨後，他們也給我們發了一份User Testing Report，介紹每一個flow的script以及可以做的task。我也要玩一下prototype熟悉一下。

(2) Research Plan

• Test Plan

在見user做testing之前的時間，我便快速的思考一下要準備的東西

本來是打算每個受訪者每個flow只做一個version，然後我會口述另外的version，讓他們了解兩個version之後給feedback的。到最後真的做測試的那天按需要改成他們兩個version都做😂，原因是受訪者數量不多，而且在跟第一個受訪者（也是其中一個stakeholder）做testing的時候發現其實需時不多。

• Questions

提前準備一下我可能要問的問題，回想起來，好像沒有按順序問這些問題😂，但是在過程中也有cover到，太好了。而且在訪問期間發現其他問題也一同問了。

• Data Contents

準備這部分的時候我的思路是，我要記下什麼。包括User Feedback, Observation, User Profile。

User Profile包括用家類型（是不是end user）、是否有使用舊版本app的經驗、平時是用什麼device、接觸這件事的頻率、年齡段、在那一個location工作

(3) Pilot Test

剛好有認識的人是做一樣的工作！太感動，當天晚上就找ta幫忙做一個Pilot Test。

完成這個Pilot Test之後，我也會把數據記下來。而且在記錄數據的時候調整了一下Data Content的結構，加入了“How”。我希望將受訪者完成的具體步驟也記下來，因為這個可以當作一個test report供vendor design team參考。

通過這個Pilot Test，除了可以練習問問題的方式，還可以提前得到一些insight，在後面的test完成了之後發現Pilot Test的insight有可能是有效的（很神奇）因此，已經對user的workflow有一定的了解，以及有一些初步的recommendation出現，雖然不知道之後會不會用到，但是記下來總是好的。

Run the Test

接待我的是其中一個end user（U），U也是其中一個stakeholder。U跟我找了一家咖啡廳坐下來，設置好equipment（錄影的手機）之後我給U講解了一下這個user testing的作用以及方法，然後跟她demo了一次。當然，因為U也是其中一個end user，因此她的data我也會記下來作為參考。

然後U幫忙聯絡每個受訪者來到咖啡廳來做testing，由於我跟其他user是初次見面，所以U（她人太好了）也會在旁邊陪著，或許做observer。一方面，可以讓U知道其他end user的使用方式和想法，另一方面，她可以安撫受訪者緊張的心情😂。（雖然我已經告訴他們把這次的testing當作是試玩game就好了，完全無壓力）

每個受訪者做完測試之後，我都會讓U問她想知道的問題。而且我發現，每次做完一個受訪者，我們都會有一些更加深入的問題會出現。例如，當我跟U做完demo之後，我們會發現一些複雜的case出現，那我之後每一個受訪者我都會問他們關於這些複雜的case的處理方法是怎樣的。

然後我會著重觀察前一個受訪者的做錯的地方，看看接下來的受訪者會不會出現同樣的情況。

每一個受訪者做完一組測試之後，都會有屬於他們自己的behavior，我會根據他們的這些特別的behavior問他們為什麼要這樣做。例如，有一個受訪者在按了checkbox以後，也按了一下edit，我問他為什麼要按edit，他說“只是想知道裡面有什麼而已”😂 interesting

每個受訪者每做完一個case，我都會先記下他們prefer哪一個version以及原因，還有他們特定的quote，feedback

Flow

1. 打招呼，介紹自己
2. 介紹要做的test是關於什麼的，一共有3個case，每個case有2個version
3. Follow up questions
4. 了解他們的user profile
5. 閒聊一下（有可能會有feedback，例如有一個受訪者透露他之前用過哪些類似的app，可以作為參考）

Input Data

• 我會先把筆記本記下來的feedback先整理，填在準備好的template裡
• 然後看video，把他們的behavior寫下來
• 把我觀察到的卸載observation裡面

Result & Analysed logics

加上Pilot Test一共有5組數據

1. 總結preferred version的數量。Case1 — v1(3):v2(2)。還發現了一個有趣的pattern——沒有用過舊App的兩個受訪者是選v2，用過舊app的受訪者選v1。原因是v1某一些design是跟舊app一樣的；Case2 — v1(3):v2(2)；Case 3 — v1(0):v2(5) 非常明顯case3要用v2
2. 發現在case1每個受訪者都會有相同的pattern/動作，要mark defect的時候先按location再選type。因此，proposed flow要將此考慮在內
3. 大多數受訪者會在完成一個動作之後按“save” button，但是這個button或許他們不想按，因為多了一步。因此，我會propose auto save或者將button的內容換掉，設置在最後一步，也就是說這個button是他們在這個頁面完成所有的動作之後按的
4. 在case2的version1有些受訪者會不知道checkbox是可以按的，或者不知道checkbox是用於多選然後做下一個動作。因此，我會propose用一個action button將checkbox收起來，例如：select to mark，按了button之後checkbox才出現
5. 在case2的version1有兩個很長的button，通過testing之後發現受訪者幾乎不會在意button裡面的內容是什麼，但是當他們按了checkbox之後要做下一個動作之前，就會閱讀button來確認是否要做這個動作。因此，我會propose頁面的按鈕的wording簡明扼要一點，不要讓user花時間閱讀思考文字內容
6. case3的version2是從horizontal view轉換到vertical view來選擇下一個項目的，不少受訪者認為手機屏幕轉來轉去會有點不習慣。因此，我會propose加一個horizontal view的頁面給user選擇下一個項目
7. case3的version1是當user按了一個提交button之後，直接跳到一個項目。不少受訪者認為，這樣子會侷限他們去下一個項目，而他們並不想按著順序去下一個項目，他們比較傾向於自己選擇去哪一個項目，因此，#5 proposed的的那個horizontal的頁面剛好吻合
8. case3跳轉下一個項目的時候，有user認為要有一個list給他確認一下剛剛mark的東西才讓他選擇下一個項目，因此，我會propose在期間加一個full list的頁面
9. 有幾個受訪者會經常想按collapse按鈕將panel收起來，可想而知user是比較喜歡簡潔的頁面看floor plan

Insights & Findings

根據上面分析的結果，將需要改進的頁面按照3個case依次分類記下來

有一些是提出兩個可行的flow，可以讓大家投票決定哪一個更好。但是因為做決定的stakeholder，vendor也就按照stakeholder選的version做修改。

有一些是提出可以改進的地方，例如加入需要的元素/button，或者加入一個頁面。

遇到還是不清晰的地方，我們都會在上面留言討論，得出最合適的方案

Lessons

• 幸好做了Pilot Test。Pilot Test真的很重要，可以讓我先練習一次，熟悉一下所有case是怎樣運行的，story是怎樣的，我應該問一些什麼問題等等。也讓我預見有可能出現的情況，受訪者有可能遇到的問題。
• 練習真的很重要。這次我發現自己學會了提問以及引導受訪者做action的講話方式，可以做到neutral。
• 還是需要練習更多，因為有時候還是會有意無意的輕微有一點bias，例如，當受訪者按了一個沒有反應的地方，他有可能會慌亂，然後會按其他地方，遇到沒有反應的時候他就會懷疑是不是自己做錯了。在這個時候，我就要引導他走另外一條路，或者用另外一個思維，我會說：“當你不可以先按這裡，那你就需要先找一下XX，那你會怎麼做？” 當他接收到我說的另外一條路的時候，他會本能的問我“是這樣嗎/是這裡嗎/哦是這裡”，然後我也很本能的回答“對了！/就是了！”😂
• 每一次訪問完一個受訪者，都要把feedback粗略記下來，總結一下在哪一個地方會有問題，在下一個受訪者做訪問的時候可以多觀察這些問題是否會出現
• 有多一個人幫忙會更好，一個人做testing其實真的會有點吃力，因為要做moderator也要做observer，還要做筆記。
• 有Stakeholder一起做訪問，他們做observer的角色效果會更好。因為可以讓他們了解user是怎麼用以及怎麼想的，多聽一些他們以外的意見
• 一定要選一個安靜一點的地方，以及你的device要設置好。
• 勇敢問問題，不懂就問，不了解就問，說不定他們很樂意告訴你

感謝你看到這裡！