可用性測試

　　剛剛從公司的培訓課程中學到了"Usability Test"，沒想到這么快就用到了實踐中，雖然這次的可用性測試不是很正式的從公司外部請用戶來做，也沒有用單面透視玻璃對用戶行為作“暗訪”，但同樣達到了一定的效果，找出了產品中的一些問題。

　　今天的測試是請用戶按照產品的文檔完成產品的安裝和一個Kernel模塊的安裝。在寫那份文檔的時候，我已經自以為很充分的考慮了各種情況，為不同的用戶，不同的場境進行了描述，原以為問題不會太大，沒想到測試的結果很讓我驚訝。

　　用戶根本不看文檔。如果作為一個有經驗的用戶，也許在拿到軟件包時就是自信的打入./configure && make && make install來完成安裝。原以為這次用戶在我們強調了文檔的情況下用戶會看文檔，結果用戶還是沒有看，只有在遇到問題時才會想到文檔。準備了 README和INSTALL兩個文檔，原以為用戶會看INSTALL，沒想到用戶總是喜歡挑短的README看，有詳細步驟的INSTALL就不愿意看。
　　當用戶發現做不下去要看文檔時，我們發現用戶只喜歡看文檔中列出的命令，而對于命令前后的解釋性文字一率是視而不見。但用戶有時又無法分辯到底他 看到的是句子還是命令。如果文檔中列出的命令用戶不熟悉，或者看不懂，他操作起來會很沒有信心。用戶有時無法區分"INSTALL"文件和"make install"這條命令中的install有什么區別。
　　用戶無法看到文檔中的重點，當大篇的文字出現在屏幕上時，用戶無法找到文章中的重點，三位測試人員不約而同的對文檔中對他們完全沒有用處的一段文字表現出極大的“興趣”。
　　用戶不看屏幕的提示，屏幕用大寫字母打出WARNING時，用戶仍然不加思索的回答yes，繼續有危險的步驟。
　　用戶記不住自己做過的事情和屏幕上的信息，僅管文檔提醒用戶要記住一行提示，用戶仍然不會去記它。
　　如果不在文檔開始的地方提醒用戶可以把文檔打印出來看，用戶想不到把文檔打印出來放在手邊。
　　用戶對終端上出現的彩色的字符比較敏感，如果把上面那用戶看不到的大寫WARNING改成閃動的紅色字符也許就很容易引起他們的注意。
　　如果用戶在努力很久后，完成了安裝過程，但產品卻沒有正常工作，用戶會非常沮喪。
　　當用戶第一次失敗時，他會認為是自己的錯誤，如果連續兩次失敗，他會對產品失去信心。
　　如果用戶的相關經驗可以指導他直接完成任務，事情會很順利。如果他的經驗無法讓他直接得到正確的結果，他完成任務的效率會比沒有經驗的更差。
　　用戶如果不熟悉命令行，讓他做命令行的操作會非常痛苦，給他命令依樣畫葫蘆也沒用。
　　用戶希望文檔可以步驟更清楚，而不一定要列出太多的信息。用戶希望有Wizard形式的安裝過程來代替文檔。
　　其實當我列出這些條條來后，反而感覺不是那么驚訝了。這些不都是我們平時在用軟件時的一些習慣嗎？只不過怎么在做軟件時真正把用戶的這些體驗設 計進去，真正做到以用戶體驗為中心的設計，這才是真正很難做到的。程序員總是在寫程序時把程序的思路放進產品，而很難把用戶的體驗放進去。

　　實話說，我一直覺得自己在做程序時是很注重用戶體驗的，但經歷今天的可用性測試才發覺，可用性和良好的用戶體驗存在于產品的每一個角落。以前我 總是太Focus在一些細節的地方，精確到每一個快捷鍵的設計、圖片一個像素的位移這些很細微的角落，有時卻忽視了整體上的可用性。

　　同時，可用性的實現，尤其是一些細節上的東西，往往會跟產品的開發周期和Schedule形成相互的制約，怎么在這種相互的制約下達到一個最好的平衡，也是一個要在實踐中反復體會的話題。

原文轉自：http://www.kjueaiud.com