牛人，給你來個突擊測驗：你怎麼知道你的應用程式能夠正常工作？當然，也許你的程式通過了編譯。也許它通過了所有的單元測試。也許它還成功通過了qa的嚴酷考驗。也許它被成功部署到了乙個正式的伺服器，或者被打包成了乙個安裝程式。也許連beta測試人員都簽字認可了。
然而，所有這些都不能說明你的程式能夠正常工作。
使用者真的能理解你的應用程式嗎？他們能夠使用你的程式去完成他們的工作嗎？這才是「能工作的應用程式」的定義。我在第一段羅列的所有東西都算不上什麼。實際上，如果你不找來真正的使用者做可用性測試（usability testing）的話，你是無法知道你的程式能否正常工作的！
你會定期給你的應用程式做可用性測試嗎？
你應該去做！這就是我的觀點。steve krug有本書叫《don』t make me think》，其中有個中心思想就是：可用性測試對於任何軟體專案來說都是必需的。krug有個簡單易行的方法來做可用性測試，他稱之為「跳樓大減價」的可用性測試。
譯者注：《
don』t make me think
》的中文譯本是《點石成金：訪客至上的網頁設計秘笈》，由機械工業出版社於
2006
年出版。
可用性測試已經存在很長一段時間了。它的基本理念很簡單：如果你想知道你的軟體、**或vcr的遙控器是否容易使用，那麼在一些人嘗試使用它的時候觀察他們，記下他們在**碰到了問題，然後修正這些問題，之後再度測試。
不過，在最開始的時候，可用性測試的花費非常昂貴。你需要建立乙個可用性實驗室，它帶有一間位於單向玻璃後面的觀察室；至少要有兩部攝像機，分別錄製使用者的反應和他們正在使用的東西。此外，你還得招募大量的測試使用者，以得到具有統計意義的結果。這是科學研究。每次測試需要花費2~5萬美元。因此這種活動不會經常發生。
但是在2023年，jakob nielsen寫了一篇題為「usability engineering at a discount」（打折的可用性工程）的**。他指出，可用性測試不是非得那樣做不可。你可以不需要可用性實驗室，而且就算測試使用者減少很多，也能得到同樣的結果。這個想法是乙個巨大的進步！惟一的問題是，10年以後的人們仍然覺得可用性測試不便宜，聘請乙個人主持一次測試仍然得花上5000〜15000美元。結果呢？雖說可用性測試比以前發生得多了，但還是不夠頻繁。
krug指出，除非你對可用性測試有牴觸情緒，否則它不難！即使只請乙個人來做可用性測試，你多多少少總能得到一些有用的結果，比如下面的情況：
顯而易見，完全不做可用性測試是一場災難。但還有一點不是那麼顯而易見的是，只有少許幾個人進行的可用性測試也能相當有效。而且，如果你遵循krug給出的指導原則，你的低保真（low-fi）可用性測試會進行得更加順利：
dmmtchapter09_for_personal_use_only.pdf）。我前面只是初略地介紹了一下，如果你想知道更多的細節，還是去看書吧。
可用性測試沒必要做得很複雜。如果你真的想知道你正在做的東西是否對路，邀請一些人來使用它吧，並且你待在旁邊仔細觀察。沒別的，也就是從會計部把joe抓過來，從市場部把sue抓過來；只要不是直接參與這個專案的，附近的人隨便抓，然後請他們使用你做的東西。不要告訴他們做什麼。給他們指定乙個任務，然後提醒他們，在他們動手做的同時把心裡的想法都說出來。而你只需要靜靜地坐在後面，仔細觀察。根據我個人的經驗，我可以告訴你，結果往往是令人驚訝的。
可用性測試的好處是毋庸置疑的。你儘管去做吧，這樣才能真正體會到那些好處！
可用性測試
工作一直緊張，但今天還是岔出了一件事情，就是對我負責的模組進行使用者可用性測試。兩個小時的測試還是有點收穫，小記之。剛剛從公司的培訓課程中學到了 usability test 沒想到這麼快就用到了實踐中，雖然這次的可用性測試不是很正式的從公司外部請使用者來做，也沒有用單面透視玻璃對使用者行為作 暗訪...
可用性測試
1.頁面部分 1.頁面清單是否完整 是否已經將所需的頁面全部都列出來了 2.頁面是否顯示 在不同解析度下頁面是否存在，在不同瀏覽器版本中頁面是否顯示 3.頁面在視窗中的顯示是否正確 美觀 在調整瀏覽器視窗大小時，螢幕重新整理是否顯示 4.頁面特殊效果顯示是否正確 2.頁面元素部分 2.元素是否顯示 ...
Web可用性測試
專案 問題 答案 yes no n a 瀏覽1 對瀏覽者所處網頁有清晰的標記？2 有清楚指向主頁的鏈結？3 各主要部分都可以由主頁進入？4 有 索引，已備需要？5 架構簡單，沒有不必要的分級？6 有易用的搜尋功能，已備需要？功能1 所有功能都有清晰的標籤？2 不需要離開 即可運用各必需的功能？3 沒...