易用性測試實務問題討論 😉
Gogolook Design team 有個很棒的自發活動叫 product open space，來參加的同事們會提出幾個自己想跟大家討論的議題，投票後針對當週票數最高的主題討論。有時發問、有時單純分享自己經驗，是個輕鬆的分享場合。
某次 product open space 的主題是 「易用性測試」，設計師們提出了不少之前自己做易用性測試時會遇到的問題，我也分享了一些自己的經驗跟想法。以下是當天討論的彙整內容。
1. 易用性測試感覺可大可小？哪些情境下可以做易用性測試？
我以前試過用最基本的紙本 Wireframe 進行易用性測試，也有試過極高擬真的 prototype，易用性測試絕對是可大可小。
（雖然每次都跟設計師說真的不要再精修 prototype 了，但每次設計師在測試前都會無法克制的把 prototype 越調越高擬真 😳）
prototype 越高擬真，當然受訪者越能在不需講解的狀況下開始測試，但線框稿也是能做易用性測試的。主訪者掌握測試目標後，可以提供其他素材和說明，讓受訪者同樣能體驗產品、提供初步看法。
易用性測試受 prototype 限制的狀況是常遇見且絕對可以先準備好的，所以仍要回到最源頭問：什麼情況下要作易用性測試？
我的想法是，當你面臨的問題：(1) 查網路資料沒有很適合的解答 (2) 團隊內不太有共識或難以決定時，就可以做易用性測試，讓受訪者的回饋來幫助你決定和改善產品。
只是要注意的是，滿多團隊平常沒有足夠資源找 real user 做易用性測試。有時大家會累積想測的東西，一次測一堆任務。導致單次測試時間偏長、任務數量多，受訪者、主訪者、協助者都會滿累的。但其實測試跟開發一樣都是可以敏捷迭代進行的。
當有想測的內容時，可以先找親友測測看，或是盡量找公司內不同團隊的人做走道測試。當手上 task 完整到不太有內部爭議時，再找外部 real user 來測試，看看有沒有漏掉的盲點。
易用性測試並非追求一次到位、包山包海的測，小範圍的迭代測試會更適合開發節奏快或資源有限的團隊。
2. 易用性測試要假定 TA 嗎？不設的話，對測試結果會不會有影響？
在規劃測試時，研究員通常可以看這次預計測試的內容，大致抓出要找的受訪者條件，再跟團隊討論是否需要調整。所以基本都是會預設 TA 的。
但不設 TA 、設得不夠細，或甚至是想設細一點但找不到人，只好給材料讓受訪者角色扮演，會不會對測試結果有不好的影響？通常我會看產品/任務的性質去考量。
產品/任務的性質
如果產品/任務的使用情境較沒有門檻、面向大眾，受訪者條件就可以設得比較寬鬆。如果使用上需要特定知識或情境，就會建議要找到符合條件的受訪者，測試結果的偏差會比較小。
雖然上一點才說易用性測試敏捷的測比較好，如果沒有找外部 user 的資源，先找公司其他同事走道測試也是好方法。但當產品的使用範圍越 niche，找到越符合條件的受訪者，訪談內容通常會帶出額外發現，這是訪問同事不太容易發現的。
所以平常找內部同事幫測能處理掉多數的易用性問題，但找 real user 能讓產品再進一步，有機會更中 TA 的心。
以 Gogolook 旗下產品為例，Whoscall 是協助大家處理陌生通訊問題、辨識你的陌生來電，幾乎是所有人都能用到。但依 user 的背景和特質，使用的動機強度可能會不太一樣。所以如果是想測試陌生號碼辨識、反查這類功能的話，受訪者的條件就能放比較寬。
但若是貸鼠先生的信貸產品頁面測試，由於金融領域會有比較多專業知識，是有相關背景、曾申貸、有做貸款功課等經驗的人才會了解的，對貸款沒有需求的人可能不太知道，留意到的重點就會不太一樣。這種情況下，受訪者的條件就會有比較多要求。
同樣的，主訪者可以簡易說明貸款懶人包，讓受訪者快速理解。但實際經歷過申貸的人，他留意到的細節一定會和沒有切身經驗的人有差異。
在有資源的情況下，我們會盡力去爭取找到符合經驗的受訪者。但若沒有資源，找不同 squad 的同事來試試看，能排除明顯的易用性問題，同樣也會有收穫的。
3. 如何確保受訪者的表達方式是我可以理解的？怎麼知道他是不是真的有理解我的問題？
通常我會用 (1) 測試前的電話訪問 和 (2) 測試中的覆述，來確認受訪者的表達狀況和我們雙方的理解是否一致。
測試前的電話訪問
Gogolook 最常用的招募方式是這樣的：我們利用不同管道接觸潛在受訪者，請他填寫一份短問卷，內容包含基本的行為問題，詢問他受訪的意願。若他願意受訪，最後再留下聯絡方式，研究員會主動聯繫他。
Gogolook 的使用者們都對自己的個資保護有一定程度的要求，所以若不是願意受訪的人，我們不會請他留下可辨識到個人的資料。
在測試前的電話訪問裡，我們會問一些開放式的問題，來看受訪者是否能順暢的表達他的看法。若文不對題，或發現他不是這次研究的目標對象，則再禮貌地和對方說明，未來若有合適的研究會再主動邀請他。
不過要留意的是，現在的受訪者多半不太喜歡講電話（我也是）。電話中回得簡短不見得代表他不健談或不願意分享，多打一些電話比較能建立自己的判斷基準。
測試中的覆述
每當訪談到一個段落，我會嘗試把剛才受訪者跟我說的話，現場做個小統整，請他聽聽看是不是符合他剛才跟我描述的內容。
這時候如果他想到剛才漏掉的內容，也會在這時候補充。這樣能確保受訪者有盡全力的回想到這次訪談主題裡他的所有經驗，也能藉由主訪的口再快速提一次故事，確保雙方認知在同一條線上。如果你理解錯了，受訪者會在此時糾正你，那又有再調整的機會。
有個隱形的好處是，受訪者通常不像研究員這麼熟悉錄音錄影設備，有時講話聲音會比較含糊。研究員快速綜整能確保這個階段的紀錄完整，若有同步旁聽但剛剛恍神的同事，這時也能再聽個懶人包。
這樣做的壞處大概就是回聽錄音檔時，會聽到自己一直在整理前個段落的話，有點不好意思就是 😳
4. 如何確保自己能客觀提問，不帶主觀意識？
最快的方法就是找個研究員，自己的設計不要自己測，讓旁觀仔研究員為你服務 😆。
自己的設計自己測時，真的是很難保持客觀 。
我會建議可以多準備一些中立的罐頭發問句，例如「你會先留意到哪些地方？」、「這個地方你覺得怎麼樣？」之類的，當感覺自己情緒很滿快要辯護時，可以先用這些罐頭問句擋一下。
另外就是回聽自己的錄音檔，雖然真的全身尷尬，但這時就可以記下自己也許不那麽客觀的狀況，不斷提醒自己。研究員也是得要一直提醒自己不要不小心問出引導性問題的。
5. 如何確保在有限的時間內問到想問的問題？
時間控制真的是滿難的。經驗豐富的焦點團體主持人通常能精準控制每個段落的時間，也能識別出哪些點是值得深挖的。控制時間及確認訪問內容是否需要再深挖，都需要經驗累積，很難一次到位。
所以我會建議與其在控制時間上苦惱，不如提升測試或訪談的次數，讓這次排不進去的問題、這次訪談才發現的問題，可以整理到下次再來問。
在 Gogolook，我們運用每次發問卷累積的受訪者資料庫，當團隊現在有些具體問題想問，但問題量都沒這麼大時，就做小規模的測試和訪談。受訪的時間短、也能在一個 sprint 內取得資料，協助團隊調整方向。
以上是我們的日常討論，都是大家的經驗交流。如果你有其他想法或建議，也歡迎一起討論，讓產品越來越好 💪
