簡而言之，網站可用性測試基礎知識

可用性測試是改進網站的好方法，但它通常被認為是實驗室中昂貴的錢槽。 雖然這是測試有時可能會發生的事情，但這往往是邊緣情況。

可用性測試是改進網站部分的有效且經濟實惠的方法。

為確保您運行這些類型的測試，您需要了解何時以及如何執行正確類型的測試。

網站可用性測試基礎

可用性測試很重要，因為人們所說的和所做的可能是非常不同的事情。

之所以需要這些測試，是因為觀察用戶與網站的交互方式可以幫助您解決網站上的大多數關鍵問題，而拆分測試和多變量測試則無法做到這一點。

不需要很多用戶就可以了解您的網站，並且並不總是需要眼動追踪和可用性實驗室。 在給定正確的場景和目標的情況下，僅觀察12-15 位用戶瀏覽界面就可以獲得很多價值。

在您計劃正確的目標之前，您需要了解哪些目標適合進行可用性測試。

與拆分測試的區別

拆分測試是一個強大的工具，但它也有其局限性。 與可用性測試相比，它是面向量的，而不是面向任務流變化的。

拆分測試旨在改進頁面，而不是改進網站的整個部分（例如整個結帳流程）。 它們還設計用於統計意義，而不是特定的用戶洞察：

統計意義對於改進頁面上的元素非常重要。 但是，觀察用戶嘗試在給定界面上做某事可以為您提供特定的、可操作的方式，您可以更改整個工作流程——結賬順序、查找聯繫人的方式、定價的方式。

拆分測試無法做到這一點。

您可以從可用性測試中獲得的見解非常適合在開發週期的各個階段改進項目。

可用性測試的項目階段

您對界面進行更改的能力會隨著時間的推移而減弱。 同時，進行更改的成本會隨著時間的推移而增加。

拆分測試和可用性測試之間的另一個區別是可用性測試幾乎可以在項目的任何階段進行，而不僅僅是在生產環境中進行。 你不需要任何東西來運行可用性測試。

隨著在項目中越深入進行更改的成本越來越高，在開發階段的早期進行可用性測試通常是一個好主意。 也就是說，在任何階段運行測試都比根本不運行任何測試要好：

還沒有建造任何東西

您可以在競爭對手網站的可比較部分上進行可用性測試。 這將告訴您什麼在類似界面上有效，什麼無效，並且您可以避免競爭對手的陷阱。

早期迭代

在開始開發之前，您可以使用設計的紙質原型來發現關鍵問題。

後期

在您投入生產之前，您可以創建一個可點擊的界面原型以進行測試並以這種方式運行測試。 可點擊的原型比實時代碼更便宜，因此在這裡發現問題至關重要。

最終設計

您應該計劃定期對網站最薄弱的部分進行可用性測試，即使是在生產環境中也是如此。

無論您將在哪個階段運行可用性測試，您都需要某種方式來確定優先級。 您可以使用一些工具來簡化此操作。

尋找測試部分

為了獲得最大的收益，您需要找到改進後最能移動針的區域：

高失敗率任務

如果你有一個調查工具，你應該使用諸如“你想在網站上找到什麼”和“你找到了嗎？”之類的問題。 確定任務成功率。 您可以查看可用性測試候選人的任務成功率低和流量高的部分。

轉化的關鍵路徑

對轉化特別重要的路徑是測試的好地方。

可用性測試的類型

您可以親自或通過遠程測試軟件（例如 Skype 或 GoToMeeting）運行可用性測試，只要您可以記錄屏幕操作和通話音頻。

現場測試成本更高，但可能讓您觀察更多事物。

遠程測試將允許您在預算範圍內進行操作。 但是，它不允許您在網站用戶說話時查看他們的面部表情和肢體語言等內容。

現場可用性測試

您可以在公司的辦公室、網絡訪問者的環境或專業的可用性實驗室中進行可用性測試。 每個都有優點和缺點：

公司辦公室

您不會獲得眼球追踪的具體觀察結果，也不會在 Web 訪問者瀏覽時看到他們的實際環境以查看有哪些干擾。 但是在會議室中進行隨意的可用性測試可以讓來自不同團隊的更多人參與進來，展示原型，並有一個不太正式的設置，可以讓訪問者大聲交談。

網絡訪客的辦公室/家

用戶自己的環境可以向您展示他們在導航時可能會分心的情況。 它還可以向您顯示典型潛在客戶可能擁有的網絡速度。 但是，攜帶多個團隊成員可能成本過高，而且您將無法展示專有原型。

可用性實驗室

在可用性實驗室舉行的會議成本高昂，而且比其他環境更正式，因此讓用戶大聲說話可能更難。 但是，您或許可以使用眼動追踪技術從注視模式中收集更多信息。

現場可用性測試往往更昂貴，但它們通常是值得的，因為您將獲得有關界面的額外信息。

遠程可用性測試

遠程可用性測試可以在預算範圍內運行，但它們往往不像他們的本地表親那樣數據豐富。 但是，對於大多數界面，遠程可用性測試應該足以發現最關鍵的問題。

有兩種方法可以運行遠程可用性測試：

無節制

這是運行可用性測試的最便宜的方法。 您可能無法獲得確切的目標用戶，並且如果您不進行採訪，您可能無法收集到盡可能多的信息。 但是，它是一種快速、廉價的方式來獲取有關您站點上的任務的反饋。

• 您選擇的界面會發送到一組預先選定的測試人員。 然後，您發送有關他們執行哪些任務的說明。 一旦他們執行任務，您就會獲得有關他們的成功率和評論的統計數據。

有節制

版主是可用性測試的一大福音。 如果你可以的話 …

1. 與用戶建立 GoToMeeting、WebEx 或類似會議，
2. 請求允許錄製會話，以及
3. 在他們在您的網站上執行任務時向他們提問

......您將獲得比未經審核的測試更多的信息。

進行無節制的遠程測試

因為無節制的遠程測試與其他類型的測試非常不同，所以讓我們先解決這些問題。

關於無節制的遠程測試，您至少需要了解以下內容：

• 會話較短，因此您需要保持專注。
• 由於參與者將閱讀任務並嘗試執行它們，因此您無法深入了解他們為什麼要做他們正在做的事情。
• 引導者無法與參與者互動，因此與其他類型的可用性測試相比，任務完成時間等數據變得更加重要。
• 參與者可以有簡短的任務後評論。 在這裡，您可以收集有關他們與您的界面交互時的想法的一些信息。

招募參與者

如果您正在運行現場或遠程主持測試，則需要招募一組參與者進行可用性測試。

這部分對一些公司來說可能是一種威懾，因為它聽起來很昂貴，但它真的不應該成為一個太大的問題。 在低端，有15 個用戶，每位用戶 30 美元，您可以以不到 500 美元的價格讓參與者參與完整的可用性測試週期。

對於現場測試或主持的遠程測試，您可以從幾個不同的來源獲得參與者：

• 客戶名單。 如果您有現有的客戶列表，您可以向他們發送參與可用性測試的邀請。
• 攔截。 如果您可以使用 Ethnio 或 Qualtrics 等工具在您的網站上創建攔截，您可以向一小部分用戶顯示可用性測試邀請。

您通常希望為用戶參與可用性測試提供激勵。 根據測試的複雜程度，提供 25 到 100 美元的禮券或類似的東西。

當您擁有一整套測試人員時，您通常會需要一些額外的“浮動工具”。 這些人獲得的激勵比主動測試人員小，但可以在人員不可用時替換主動測試人員。

分組可用性測試

為了充分利用參與者，請僅讓少數人測試特定設計。 四到五個人應該可以讓您了解界面的大部分問題。

這個想法是測試一個界面，捕捉大部分問題，然後在啟動生產版本之前再做兩次。

準備任務

對於用戶任務，您需要兩件事：

• 要測試的網站、原型或界面的一部分
• 用戶在該部分實現的目標

例如，如果您經營一個旅遊網站，您可以嘗試讓用戶找到最便宜的 3 星級酒店，該酒店在特定日期在悉尼提供免費上網和免費取消服務。

對於這種類型的任務，特異性很重要。

設置日期和尋找酒店可能很容易，但過濾機制對於尋找帶 WiFi 或免費取消的房間可能會很笨拙。

根據您擁有的網站類型或您正在測試的部分，需求可能會更加基本，特別是如果您正在測試的客戶旅程部分往往處於早期階段（即“在本部分中查找參考談論提高你的信用評分”）。

無論您最終將部分和目標組合在一起，您都需要準備一份同意書，並為您的參與者提出一組問題。

準備同意書

同意書可以包含有關您將如何使用數據以及如何不與其他公司共享數據的措辭，但基本組成部分如下：

• 參加測試是自願的。
• 屏幕和音頻將被記錄。
• 參與者可以隨時提出問題。
• 如果他們感到不舒服，他們可以要求研究人員停止可用性測試。

可以在 usability.gov 或 Steve Krug 處找到同意書的基本示例。 您可以參考這些作為基礎並添加您需要的項目。

準備問題

在進行可用性測試時，您可以做的最重要的事情是讓參與者大聲思考。 也就是說，參與者應該談論他們在瀏覽您的網站或原型時所經歷的事情。

為此，您需要提出以下問題：

• 您將從哪裡開始尋找信息？
• 在你點擊任何東西之前，你能告訴我你期望會發生什麼嗎？
• 這符合您的期望嗎？

這個想法是促使參與者揭示他或她是如何考慮界面的，而不是引導他或她走上一條特定的道路。

當您為測試將要運行的部分準備問題時，請嘗試指出這些元素的可發現性以及參與者需要的內容是否容易找到。

在提出問題時，請確保您至少滿足以下標準：

• 文筆枯燥而具體，而不是可愛
• 無前導——避免影響用戶在頁面上的操作

運行可用性測試會話

在進行實際可用性測試之前，您需要做一些事情：

• 確保您可以錄製音頻和屏幕。
• 至少有一個主持人和一個觀察員。 這樣，當主持人提問時，有人可以做筆記。
• 歡迎參與者，簽署同意書，並給予參與者獎勵。 這個想法是將激勵與“做得好”的測試分開。

簽署同意書後，當用於測試的屏幕已經打開時，向參與者解釋他們沒有接受測試。 沒有正確或錯誤的答案。 界面正在測試中，因此參與者應該盡可能坦誠。

當你提出問題時，你可以回應參與者的陳述，但不要給他們留下關於如何在執行任務時找到他們需要的東西的線索。

當會話結束時，讓自己能夠輕鬆評估這些：

• 完成任務的時間——完成任務通常需要多長時間
• 任務成功率——有多少參與者完成了任務，有多少沒有完成
• 失敗原因——參與者無法完成任務時無法理解的領域或機制

每項任務完成後，您還可以要求他們給您一個主觀滿意度分數。 當您改進界面時，您可以將此分數用於匯報會議和定向趨勢。

完成所有任務後，感謝參與者並開始計劃匯報會。

進行匯報會

讓你的可用性測試發揮作用的最好方法是讓它成為一項旁觀者的運動。

如果您在辦公室舉行可用性測試會議，請花一些零食來吸引人們觀看用戶通過（有時甚至無法使用）您的界面。

很少有事情能比看到用戶四處亂竄，不知道該怎麼做更快地解決爭論。 它消除了相互競爭的內部需求，以展示某些東西，關於措辭足夠好的爭論，以及一系列其他問題，這些問題可能很難單獨通過網絡分析和拆分測試來解決。

• 如果您在現場環境中進行測試，請嘗試在匯報期間提出可以用最少的努力解決的最大問題。 這應該確保需要改進的項目可以在幾天或幾週內修復，而不是幾個月（或者更糟糕的是，在您重新設計更大的網站之前暫停）。
• 如果您正在對原型進行測試，請嘗試就原型的下一版本或在匯報期間上線之前將修復的內容達成一致。

可用性測試基礎

大多數今天沒有運行可用性測試的公司應該至少運行其中一些測試，以便每年進行幾次更大的功能發布和問題優先級排序。

每年運行幾次這些測試的組織可能應該運行更多，並使間隔保持一致和結構化。 這樣，以可用性為中心的文化就可以開始形成。

如果您花時間了解可用性測試的優缺點並在適當的情況下使用測試，您將有另一個槓桿來調整以獲得轉換收益。