本節書摘來自異步社群《妙手回春:網站可用性測試及優化指南（修訂版）》一書中的第1章，第1.1節，作者 【美】steve krug，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視
妙手回春:網站可用性測試及優化指南（修訂版）
diy可用性測試是什麼，為何它很有效？為何很少人這樣做？
您為什麼拿着一隻雞在頭上揮來揮去？ 1
為了趕走大象。
這管用嗎？
您看到周圍有大象嗎？
—一個非常古老的笑話
介紹diy可用性測試之前，先讓我來說一下什麼是可用性測試。
很簡單！
觀看其他人試着使用您正在（或已經）建立/設計/建造的産品，目的是（1）讓它使用起來更容易；（2）證明它容易使用。
可用性測試的種類有很多，但它們有一個共同點，那就是都需要觀察使用者實際使用産品。
實際使用使得可用性測試與調查、訪談和焦點小組等方法截然不同。在調查、訪談和焦點小組中，您将詢問使用者對産品的看法或過去的使用體驗。
為了将各種可用性測試進行分類，一種有用的方法是，看它是定性的還是定量的。
在定量測試中，您的目的是要證明某個結論，例如“最新的版本是不是比以前的版本好？”或者“我們的網站與競争對手的網站使用起來一樣容易嗎？”；這是通過測量諸如成功率（多少人完成了您指派給他們的任務？）和完成任務花了多少時間等名額來實作的。
由于目标要進行證明，是以定量測試有點像科學試驗：它們必須嚴密，否則結果将不可信。這意味着您必須制訂測試方案，并嚴格按方案測試所有參與者2。您必須仔細地收集資料。您必須有足夠大的參與者樣本，以確定結論具有統計意義。而這些參與者必須能夠代表實際使用者，這樣才能将結果外推到更大的人群。所有這一切都意味着您必須對測試有深入的了解，并在測試中小心行事。
在定量測試中，為了避免測試結果受到影響，您通常要盡最大的努力減少與參與者的互動。在極端情況下，參與者獨自坐在房間裡，主持人通過對講機發出指令，而觀察者通過單向玻璃進行觀察并記錄資料。
那麼，什麼是diy可用性測試呢？
現在您可能猜到了，我向您推薦的測試位于定性—定量譜系的另一端。
diy可用性測試絕對是定性的，它不是要證明什麼，而是要讓您獲得用來改善産品的觀點。
是以，diy測試不用那麼正式，也不用那麼科學。這意味着您可以測試更少的使用者（隻要能獲得所需的觀點就可以），甚至可以在測試中途改變規則。例如，如果第一位參與者不能完成某個特定任務而且其中的原因顯而易見，您可以修改這個任務，甚至讓其他參與者跳過這個任務。而在定量測試中不能這樣做，因為這将導緻結果無效。
基本上，隻需要主持人和參與者坐在一起，将要執行的任務交給他，并讓他在執行任務期間進行發聲思維就可以了。
不需要收集資料，相反，開發小組成員、客戶和其他利益相關方将在另一個房間通過螢幕共享軟體觀察測試過程。測試完畢後，觀察者們将進行總結（debriefing），他們核對所做的記錄，并确定要修複的問題以及如何修複它們。
僅此而已。
有趣的是，這确實管用
在做可用性測試講座時，我總是首先進行一次現場示範——完全臨場發揮。我做的唯一準備工作是，選擇一位出席者的網站并使用它，找出訪客在該網站可能想完成的一個任務。例如，如果是衛生保健網站，我可能選擇一個有關預約挂号的任務。
接下來，我讓一位志願者充當測試參與者，并花15分鐘進行簡化的測試（真正的測試通常需要一小時，但也可能短到隻有5分鐘或長達一整天）。
結果幾乎總是相同。
參與者度過了一段美好的時光，并且因為勇敢地充當志願者而獲得熱烈的掌聲。
網站“所有者”在整個15分鐘内都忙于記錄要修複的問題，并詢問能否将錄像播放給同僚和老闆看3。
每個人最後都想：“這麼簡單？我也能做”。
測試結束後，我問，“這15分鐘花得值嗎”？所有人都點頭表示同意。
現場示範是為了表明（1）這很容易；（2）總是管用。有些人認為我之是以能夠讓測試看起來很容易是因為我做過很多次，但等到講座結束以後，嘗試過測試的每個人都認為這沒有什麼神奇之處，它确實像看起來的那樣簡單。
必須承認，我在最初幾次現場測試示範中有些擔心。但到目前為止，我做了大約50次這樣的測試，每次都管用，無論測試的是哪個網站，也不管參與者是誰。
事實上這确實管用。隻要問一問做過可用性測試的人，他都會告訴您這幾乎總是管用。隻要讓人們——任何人坐下來使用您正在開發的産品，他都不可避免地會遇到一些問題，而這些問題是大部分使用者都會遇到的。
但它為何管用呢？
隻需要做這麼簡單的工作（讓人執行任務并觀察）就總能發現嚴重的可用性問題，這看起來有些不可思議。但隻要考慮一段時間（而我考慮了多年），就能明白其中的原因。
它之是以管用是因為每個網站都有問題。每個人都可以根據自己的經驗了解到這一點。在使用網站的過程中，您經常會遇到可用性問題，而這些問題通常很嚴重，讓您極度沮喪甚至無法完成原本要做的工作。
有些成熟的網站可能沒有那麼多嚴重的問題，尤其是經過多輪可用性測試以後，但不要自欺欺人：您的網站肯定存在可用性問題。我的網站也存在可用性問題，您可以想見這有多讓人難為情。甚至amazon網站也存在可用性問題，而我對該網站的評價很高4。
它之是以有效是因為嚴重的問題通常容易發現。同樣，想想您在其他人的網站中遇到的可用性問題吧。您是否經常這樣想：他們怎麼可能不知道這種問題呢？很多最嚴重的問題一眼就能發現，幾乎所有人都會遇到。
但是對于我們自己的網站，我們卻總是認為這樣的問題難以發現。
對您來說，您自己網站的可用性問題可能不明顯，因為您知道該網站的工作方式——至少是您認為的工作方式；而使用者并不知道，這就是差別所在。
當然，也有一些嚴重的可用性問題隐藏得更深，這種問題不會有那麼多的訪客遇到。但是除非有大量資源用于可用性測試（例如，這是您的全職工作），否則強烈建議您重點排除那些顯而易見的問題，而大多數網站連這一點都沒有做到。
最後：
它之是以管用是因為觀看使用者使用産品能讓您成為更優秀的設計師。雖然大多數網站開發人員都知道諸如“以使用者為中心的設計”和“使用者體驗”等術語，但設計師、開發人員、客戶、經理和支票簽字者——所有參與設計過程的人都很少花時間觀看使用者如何使用網站。是以，最終使用者變成了抽象的概念，而設計是根據我們自己的想象完成的。
通過觀看測試過程可以讓您更深入地了解使用者如何使用産品以及如何為使用而設計産品。它賦予您設計的智慧，就像旅行可以開闊視野一樣。
為什麼很少有人進行測試
既然它這麼容易而且這麼有價值，為什麼可用性測試沒有成為每個web項目的标準組成部分呢？即使在目前，進行可用性測試的公司也很少，即使做，他們也通常隻做一次，那就是在項目即将完成的時候。
在我看來，這在很大程度上是因為大多數人都沒有任何可用性測試方面的直接經驗，他們還沒有認識到測試的價值所在。但是即使他們有這樣的經驗，也還是有很多似是而非的理由不這麼做。
例如，沒有時間。測試看起來需要做大量的工作，而大部分人手頭的工作還來不及完成呢！大多數網站開發的日程安排都非常緊張，是以一種普遍的态度是“先釋出，以後再調整”。
另外，人們普遍不願意展示未完成的産品。既然我們都知道産品有問題，為什麼還要向别人展示并讓他們告訴我們已經知道的問題？這不是在浪費彼此的時間嗎？誰喜歡向公衆展示産品的缺陷呢？
這些說法好像都很有道理，但正如您将看到的，它們并不一定正确。
faq
您讨論的是小樣本測試。通過網站分析從大量使用者那裡收集資料不是能獲得更可靠的資訊嗎？
是的，網站分析讓您能夠非常精确地了解使用者在您的網站中做了什麼（72%的訪客在5秒鐘内離開了首頁）。它的樣本非常大（實際上是所有使用者），資料是根據實際使用情況收集的，而分析工具讓您能夠提出任何統計性問題并立即得到答案。
但問題是，正如任何可用性專業人員都樂意向您指出的，雖然通過分析工具可以非常詳細地了解使用者在您的網站中都做了些什麼，但它們并不能告訴您使用者這樣做的原因。例如，如果訪客在某個特定網頁上花費了大量時間，統計資料并不能告訴您這是因為他們發現這個網頁的内容很有用并忙于閱讀，還是因為這些内容不知所雲，他們正忙着猜測呢。
而可用性測試非常适用于幫助您了解訪客的所做所為背後的原因。
在需要找出并修複可用性問題時，可以使用精确的資料分析，它們将告訴您使用者都做了些什麼，但您無法知道使用者是怎麼想的。也可以和使用者坐在一起一個小時，這能夠讓您傾聽使用者的想法并提出探究性的問題。如果必須在這兩者之間做出選擇，我每次都會選擇後者。
1 譯者注：目前，程式設計領域有一個諺語叫wave a dead chicken，指的是自己知道無效但還要做給别人看的工作。
2 在可用性測試中，将我們觀察的人稱為“測試參與者”而不是“測試對象”，這旨在強調我們測試的不是人，而是他們使用的産品。
3 有一位所有者在幾個月後寫信告訴我，看過針對其網站的示範測試後，開發小組馬上做了一個簡單的修改。他們根據前幾個月的資料進行了計算，這種修改将每年為公司節省100000美元。
4 經常有人給我發電子郵件指出他們在amazon.com中發現的問題，好像我能針對這些問題做點什麼似的。我确實是amazon的金牌會員（每年的費用是79美元，換來的是能夠在第二天“免費”發貨），但我的影響力也僅此而已。amazon做了大量的可用性測試，如果您遇到問題，我敢肯定不是他們沒有意識到，很可能隻是還沒有決定怎麼處理而已。