英文出處：Eight Lessons in Mobile Usability Testing，編譯 Be For Web
過去的幾年當中，我(英文原文作者)為不少移動產品做過測試，從戒菸應用到移動版的車輛保險網站，其中既包括在實驗室使用複雜裝置進行的測試，也包括在各種實境化的條件下進行的非正式測試。在本文中，我將為各位分享一些經驗心得，希望能幫諸位在實際工作中節約時間，提升效率。
1.關於紙質原型測試
我很喜歡Frank Lloyd Wright的一句話：“修改草稿只需要橡皮，修改實際產品則需要大錘”。在產品初期通過紙質原型與使用者進行溝通是一件事半功倍的事情，不過如果待測產品的介面需要滾屏的話，應該怎樣處理呢？
將一張包含若干屏介面元素的紙質原型一股腦展示給使用者的話，很難達到良好的測試效果。可以試著用硬紙板製作一個手機模板，如下圖所示，在螢幕上下兩端各開一道縫隙，將長介面原型插入到模板當中。這樣就可以模擬使用者在實際裝置上所看到的可視區域了。
2.螢幕錄製軟體的侷限
用於智慧移動裝置的螢幕錄製軟體在可用性測試中是很有價值的，而且它們通常不會干擾使用者的操作。不過蘋果對這類應用的審查十分嚴格，例如Display Recorder這樣的產品只有通過Cydia才可以使用，但我個人並不希望為了做測試而越獄。安卓當中倒是有一些可用的螢幕錄製軟體，不過其中的一些缺點也是蠻明顯的：
- 螢幕錄製軟體無法記錄手勢操作，例如使用者為了點選一個微小的按鈕而連著點了十多次螢幕，或是在介面上進行滑動操作等等。
- 這類軟體在效能和資源佔用量等方面具有一定的侷限性，很難支援連續一個小時以上的測試流程。
- 這類軟體在一次錄製過程中通常只能支援一個應用當中的行為記錄。
- 必須使用安裝了這類軟體的測試機進行測試，靈活性有限。
- 這些軟體通常無法與Morae一類的可用性測試工具整合使用，場外觀察者不能看到即時的記錄影像。
- 無法藉助這類軟體錄製使用者的面部表情或口頭表述。
據我所知，有兩款iOS應用可以比較好的解決其中的一部分問題。一個是UX Recorder，這款應用不僅可以記錄螢幕上的各種行為，而且可以捕捉使用者的手勢(圓圈表示點選，箭頭表示滑動掃屏等)，同時還能通過前置攝像頭及麥克風記錄使用者的表情和語音。不過最大的問題在於，這個軟體只能用來在瀏覽器中對移動網站進行測試，不能用在原生應用上。
另外一款應用是Magitest，在我看來比UX Recorder更有用些，它不僅可以記錄介面行為、使用者手勢(目前只支援點選，我相信他們未來會支援更多手勢操作)、使用者表情及語音，最重要的是，Magitest提供了一個開發包，只要開發人員將相關程式碼加入待測產品的原型當中，我們就可以為原生應用進行測試了。
3.使用“雪橇”
除了使用螢幕錄製軟體記錄使用者行為之外，我們還可以採用一種更直接和有效的方案，即“雪橇”裝置，也就是將智慧手機或平板電腦放在一個掛著攝像頭的支架上，供使用者進行測試；這種裝置的外形很像雪橇。
這種方式可以全面的記錄使用者的實際操作，無論是介面上發生的一切還是使用者執行的手勢操作都可以盡收眼底，而且雪橇上的外接攝像頭可以直接與桌面裝置上的測試、觀察軟體整合使用，譬如Morae，它可以同時支援兩個攝像頭輸入，一個掛在雪橇上，一個用於記錄使用者的表情，使場外觀察員能夠即時的看到全部測試過程。
很多設計師都使用他們自制的雪橇裝置進行測試，我自己也是如此。這其中有幾點需要注意：
- 雪橇必須足夠輕巧，使使用者可以連同移動裝置一起拿在手中進行測試。
- 不能讓雪橇遮擋住裝置螢幕，干擾使用者測試。
- 雪橇的尺寸規格應該能夠適應多種主流裝置，便於使用者通過自己的手機進行測試。最理想做法的是使雪橇外形和尺寸可調節。
- 雪橇的造型應該允許使用者調轉裝置的螢幕方向。
- 雪橇整體應該足夠穩固。
4.外接攝像頭的選取
最初，我們在DIY的雪橇上使用了羅技的兩款攝像頭，C910和C615。這兩款攝像頭的影像質量不錯，解析度很高，可以和Morae測試軟體很好的整合使用。不過最大的弊病在於這兩款攝像頭的尺寸過大，而且C910要安裝在雪橇上也不是很容易。
我們試過的另外一款攝像頭是微軟的Lifecam，解析度有720p，可以和Morae整合，同時便於安裝在雪橇上。不過弊端還是尺寸與重量的問題，另外其原生的錄製軟體也很難用。
除了傳統的網路攝像頭外，我們還嘗試了IPevo的文件攝像頭。它最讓我們喜歡的地方在於足夠輕巧，擁有很高的解析度，可以和桌面軟體良好的整合，而且本身就帶有一個很靈活的塑料支架。不過缺點也很明顯，它很難安裝在雪橇上，而且每秒的幀數太低，畢竟它本是用於拍攝文件的。
我們最終選用的是Hue的高清網路攝像頭，它很輕巧，解析度不錯，每秒幀數也足夠，本身帶有一個可調節的軟管支架，可以直接與臺式裝置連線使用，另外可選的顏色也很多。不過為了避免使用者的注意力被過多的吸引，我們還是選擇了黑色的。
5.不該使用技術裝置的時候
之前幾點實踐經驗都是聚焦在技術方面的，不過在某些時候我們還是要提倡遠離技術裝置的(手機和平板除外)。前面提到了，我們最近測試了一款專為孕婦設計的戒菸應用，為此我們招募了一批已經生了小寶寶的年輕媽媽來參與測試。這次的情況比較敏感，我們需要到這些使用者的家中進行測試，而不是請她們來實驗室。
為了營造和諧融洽的氛圍，使這些使用者更願意進行交流和表達，我儘量讓整個測試過程顯得輕鬆隨意。其中一次測試甚至是在沙發上進行的，對方一手抱著她5個月大的孩子喂著奶，一手操作iPhone進行測試。這種情況下顯然不適合使用任何影像裝置進行錄製，其他技術裝置也很有可能在這種生活化的測試環境中造成干擾。
6.考慮使用情境
我們都知道移動情境對於應用設計的重要性，但這其中的重要程度也會根據不同型別的產品而存在差異。來自comScore的統計表明，人們使用移動網際網路最為頻繁的時候是早上和晚上8點之後，這些時候人們通常是在家中的。
我們需要認真考慮自己產品的目標使用者通常是在怎樣的情境中使用產品。舉個例子，孕婦戒菸應用的很多目標使用者都提到，她們平時主要是在獨自呆在家中、手機就在手邊的時候使用這款應用。而對於我們參與過的一個旅行類應用來說，目標使用者則會更多的在真正的移動情境中使用產品。對於具體產品的使用情境的理解將有助於我們更有針對性的進行可用性測試。
推薦閱讀：
7.模擬使用者的使用情境和周邊環境
在實驗室中，我們通常都能得到穩定的無線網路連線，環境當中也不存在什麼干擾因素，但是在實際生活中，這樣的環境並不多。人們會在各種情境下使用應用，例如火車上、公交車上、排隊過程中等等。在這些情境中，網路連線不會一直保持穩定，使用者可能隨時拿出裝置使用產品，而互動流程也會隨時會被打斷。
保險界的一個客戶曾經希望我們對使用者在失去網路訊號或離開當前會話的30分鐘之後再繼續操作時的心理預期進行研究。在可用性測試的過程中，我要求使用者“設想一下你現在正在火車上使用這個產品，穿越隧道時沒有網路訊號了。” 然後我問他們在這種情況下他們希望產品在接下來應該怎樣表現。通過這種簡單的假設，我們可以在一定程度上使使用者進入一種實際情境的模擬狀態。
在我們測試戒菸應用的時候，有一部分使用者提出希望來到我們的實驗室來做測試。我們決定按照使用者的要求來進行，不過為了使環境儘量貼近於“家”的感覺，我們決定直接在觀察室的沙發上進行測試和交流，而不是使用到處都是裝置的實驗室。雖然這並非使用者的實際使用環境，不過比起實驗室來說，更接近於家庭環境的空間所帶來的測試結果可以更有效。
8.使用使用者自己的裝置，發現更多問題
在我們測試移動版的車輛保險網站的時候，我們發現Galaxy和iPhone使用者喜歡通過日期選擇器的方式完成日期的輸入，但是一位HTC的使用者卻在使用日期選擇器輸入年份的過程中遇到了很大麻煩。年份的選項太多，導致反應遲鈍，使用者在滑撥的時候一下子就將整個介面滾動起來。
在測試旅遊計劃應用的時候，我們讓使用者使用自己的裝置進行操作，發現其網路連線和部分介面反應速度確實很慢。這類問題在使用我們的測試機進行測試的過程中是很難發現的，其中有些問題在發現之後確實是可以進行改善的。
總結
圍繞移動裝置進行的使用者體驗設計早已不是一小撮UX人所進行的小領域工作了，無論設計過程本身，還是諸如可用性測試這樣的上下游相關工作環節，都需要我們投入更多的精力去思考和對待。
本文提到的這些經驗都是從我個人的工作過程中總結歸納出來的，希望能為大家提供一些參考價值，少走些我所走過的彎路。