可用性研究觀察指南

01-30

原作者：Susan Farrell ／原文章：Observer Guidelines for Usability Research ／發布時間：10-30-2016 ／翻譯：小球娘

幾句話概述：讓決策者參與可用性測試的數據收集過程。你可以根據自己的情況調整使用這份觀察指南。

你可以根據研究項目來修改這份指南說明，用以協助管理你研究項目中的觀察員。（請根據文末要求標明出自NNG）

為研究活動的觀察員提供觀察指南有兩大原因：

為避免觀察者在無意識狀態下破壞你的測試活動
從額外人員那裡獲得更多元化角度的看法和智慧，為你的研究獲得更好的分析

如何觀察可用性測試----須知

所有測試參與者請注意：

請不要忘記測試中的房間（不是觀察室）會被錄音，包括您站在屋外談話的時候。
在衛生間和走廊談論被試者和測試本身都將特別有害，即使一輪測試正在進行中，下一輪的被試者也可能在附近候場。
請避免在測試進行時高聲談笑，房間隔音不完全。
請關閉電腦提醒和手機音量。如有必接電話，請在不會被聽到或被意外錄音的地方進行。
請不要在測試進行中干擾任何人。如果必須與某人溝通，請使用字條。
當您有問題要問被試者時，請寫下來。當測試進行到尾聲時，測試主持人會專門進行收集。
我們將一起在統一格式下記錄筆記，非常歡迎您的參與。請閱讀筆記說明和材料。我們將在測試間隙和午餐時間討論筆記。

與被試者同房間觀察時：

請坐在被試者的視線以外（他們身後）並保持絕對安靜。
在進行記錄的同時請保持友善的微笑並用心觀察。
在測試前和測試中，不要與被試者對話、提供建議、糾正他們、或回答他們的問題，因為提供新信息或無意識的提供線索會導致測試結果偏差，甚至導致信息無效。由於顯得不禮貌，當您被提問的時候可能很難不去回答，但做到這一點非常重要。這時候您可以說：「關於這個問題我很願意稍後跟您討論」然後轉交給測試主持人。
只回應測試主持人的問題。測試主持人詢問被試者他們已知的問題、令他們放鬆的問題、或通過問問題了解他們的理解程度，這些情況都非常常見，作為觀察員請不要回答這些問題。找到被試者所認為的正確非常重要，即使事實上不一定正確。
注意不要干擾任何人。您的小動作、嘆氣、姿勢、面部表情、電話或衣物發出的聲音等都極容易改變被試者的行為和舒適度。如果必須，請悄悄的離開並避免來回進出房間。
如果您在記筆記，打字的噪音是允許的，但請盡量保持連續打字，這樣被試者容易將它忽略。
對於被試者帶來的幽默可以發笑，但除此之外不要隨便發笑。

如何記筆記：

多記筆記，記錄所有事件，因為您不知道其中哪些會在數據分析時顯現價值。如果筆記紙用完請添加一些（或複製粘貼更多表格欄）
即使您看見其他人記了筆記，也還應記下您自己的觀察結果，因為其他人可能忽略您所觀察到的，您本人的觀點和專長將對研究非常有幫助
每一條筆記只記錄一個觀察點，以便稍後按種分類。注意不要把觀點寫成段落，當觀點之間相互聯繫的時候，將它們排列在一起即可。如果將筆記記在紙上，注意不要寫在反面，以免之後需要裁剪成條。
當您有問題要問被試者時，請寫下來。當測試進行到尾聲時，測試主持人會專門來進行收集。
在每一條筆記上標明場景，並把您的姓名標在筆記上，以便事後出現信息模糊時的詢問。
每個測試參與者都被分配特定顏色的卡片或測試用筆記文檔。不同測試中參與者互相交換筆記文檔或代表顏色非常重要，請確保執行。

一些行之有效的筆記範例

請對所有看上去重要的信息進行記錄：

錯誤

他在地址表格中跳過了「城市」一項
她在關閉窗口前沒有點擊「保存」

系統錯誤和出錯信息提示

她第一次點擊菜單的時候下拉部分沒有彈出
出錯信息：「Database error on line 55.」

記錄點擊路徑（導航順序）可能非常有幫助：

首頁>新車>車型>黑色>型號>返回（搜索「小客車」）
搜索「福特皮卡」>Ford.com>皮卡和小客車>F-150>車型

策略和工具

他說他經常因為減郵費而購買兩件
她提到她為了尋找「聯繫我們」而點擊了「關於我們」
他使用了計算器和谷歌地圖，然後把所得信息輸入了桌面軟體

搜索詞和結果

搜索1: 來克色斯（沒有可用結果）
搜索2: 雷克薩斯（正確選擇了第三條結果）

引用

「這個很棒！」
「我以為這個用起來會像亞馬遜」

記錄任何看起來易被忽略、被誤解、模糊或令人疑惑的建議、問題、和評論（包括您自己的評論）

結論

為你的測試研究觀察員提供以上類似的指南，會給公司對用戶體驗研究的投入帶來更多回報。你可以提前把這份指南和測試活動安排一併發給確定參加的觀察員。把指南列印出來分發給測試當天臨時加入的觀察員，或在觀察室（當觀察員使用帶有觀察間的實驗室時）的每個座位放一份也很有幫助。

請自由拷貝使用這份指南並分發給你研究測試中的觀察員，請註明出處：

觀察指南, Nielsen Norman Group 授權使用。原文: https://www.nngroup.com/articles/observer-guidelines/

—————————————————————————————————

小球娘的話：

今天想聊一下我所體會到的在大公司和小公司做設計時可能（經常）出現的不同問題和挑戰。

為初創公司 / 小公司做設計的時候最常見的問題：

1. 受資源限制，無法支持「很貴」的設計。比如：設計一個filter組合，相比實時更新的filter來說，用批量更新可能更實際。因為每次更新都要跟伺服器交換一次數據，佔用伺服器的流量，導致花費增加。如果公司的財力支撐不起足夠的伺服器用量，那麼實時更新的表現就會大打折扣。如果公司根本無法負擔大量使用伺服器的費用，設計師就必須想出使用批量更新的方向來做設計。

2. 沒有章法。公司創建之初，很多細節都來不及跟上：設計流程，設計標準，資源庫……一切的一切都等著被定義。在設計標準沒有建立以前是很難控制設計元素統一性的。別說幾個設計師之間進行設計統一和資源共享是多麼困難，就是同一個設計師本人也很難保證前後作品完全統一。雜亂的設計元素會影響工作效率，增加版本控制難度，不利於團隊的整體協作。

3. 一人多能的高要求。小公司人員有限，最基本的人員配備就是：領導層，產品，市場三大塊。領導層除了把握大方向還必須事必躬親，比如coo和cto可能就直接參与產品過程。產品團隊最基本的設置是設計師和工程師，這時候他們之間的對話，理解，和相互學習就很重要。可能這就是現在業界偏愛所謂「獨角獸」人才的原因，畢竟懂得coding的設計師和有design skill的工程師總體佔少數。這兩大塊技能都建立在長期訓練和積累之上，大家時間都差不多，的確不容易兼而有之。

在大公司做設計最常見的問題:

當你眉飛色舞的講完設計以後，工程師或產品經理說：嗯挺好，可是我們做不了（攤手）

-全劇終-

...雖然你很氣，但他們這麼說也是有原因的，具體可能有這樣幾個：

1. 老樹難開新花。老牌公司的後台數據結構往往很亂，是多年一層層疊加起來的。最初的地基也許是當時最先進的，但IT界的神速更新換代決定了各種技術的淘汰率都極高。就像不換芯的老爺車，雖然一直有人在保養，但基於老零件的修修補補仍免不了容易拋錨。加上多年的人員流動，懂得原始核心的人陸續離職，新人摸不透也不敢有大動作，程序嘛你懂的，都有自己的脾氣，不能輕易去惹（有圖為證）於是後台腐爛的數據結構就往往沒有人管，在此基礎上的設計和前端優化都極受限制，進行產品美化並不能從根本上解決很多可用性問題。

2. 安全性考慮。俗話說樹大招風，老牌公司時時刻刻有無數暗箭要防（也是累心囧）尤其是如果公司產品涉及用戶敏感信息的時候，各方權衡之下保證用戶的信息安全是最重要的。比較新的設計模塊在安全性上尚未經過測試，比如過於精簡的登入流程就可能有很多空子可鑽，大公司可能都不敢冒然使用。這就是為什麼很多老公司明知自己產品用戶體驗糟糕卻仍保留原設計，頂多躡手躡腳的修修補補而已。具體來說例如一直使用冗長繁瑣的註冊信息驗證流程，或從不放棄使用互聯網誕生之初就有的設計模塊：萬年打勾框，千年單選組合，海枯石爛的下拉菜單...... 這些設計模塊雖然老氣了，但功能上過硬，用戶辨識度極高，不會造成太大使用誤解。所以當你激動的展示新潮設計時，對面的產品經理可能對它帶來的潛在安全隱患掛著一大滴汗而遲遲不敢贊同。

3. 品牌策略考慮。大公司的層級結構複雜，無論什麼工作批複時間都很長，加之如果公司產品多樣，項目經理可能考慮到品牌和策略的統一，產品地域差異等多方面，不能立即支持更新，需要等待時機，跟其他團隊全方位協調才能同時推出更新（事實上這類事情拖著拖著就沒了...）

全劇終again... 囧

4. 懶。可能這是最厚黑的原因了。對大多數不太懂程序和後台的設計師來說，工程師可以用這一句話來搪塞不容易實現的功能，以減輕自己的工作量。這個原因雖然上不了檯面，但不排除有的人這麼干。畢竟大公司里，很多上了年紀的程序猿大多拖家帶口，生活重心早就不在工作上了，他們在同一個地方一呆就是十年二十年，學習熱情不高，覺得完成任務萬事大吉的人也是有的。

做設計的一大關鍵詞是「權衡」。所有方案都有利弊，設計師的任務就是根據當前需求（用戶需求，商業需求，審美需求）在各種限制（資金限制，策略限制，市場限制）之內找出相對最佳的方案。設計師不應該是畫圖的工具，而應是在產品隊伍中引導思考的領袖，有時候也必須是「和事佬」，在用戶-開發-市場之間找到平衡，讓大家都和和睦睦的實現各自利益最大化。

以上是目前的一點思考，今後還會有補充。也歡迎大家一起來補充。

就醬，三克油！