這是篇很實用的研究測試類文章，介紹了如何通過信息架構層面和用戶界面層面的用戶研究，來定位網站的可尋性與可發現性問題的根源——究竟出在信息架構，還是導航設計。

　　網上商城建設商城眾網網絡營銷專家指出：在網站上定位不到自己想要的內容是造成用戶挫敗的首要原因之一。電子商務設計第一定律：“用戶無法購買他不能找到的商品”。因此，此類設計缺陷可不僅僅是可用性問題，它們也會對網站的盈利能力帶來巨大威脅。

　　可尋性問題和可發現性問題

　　當網站訪客頻繁使用搜索功能來尋找那些本可以通過瀏覽輕松找到的內容時，當導向關鍵任務頁面的站內流量少得可憐時，這個網站可能已經出現了可尋性和可發現性問題。

　　可尋：如果用戶認為某個網站中有他要找的內容或功能，他就可以很輕松地找到它們。

　　可發現：如果用戶不知道網站中存在某些內容或功能，他仍然可以發現它們。

　　合理的信息架構和優質的導航系統保障了網站的高可尋性和可發現性。而解決可尋性和可發現性問題的首要挑戰，便是確定問題的根源——究竟是信息架構還是導航設計的問題?以下兩個例子說明了信息架構(以下簡稱IA，即信息架構的英文 Information Architecture 的縮寫)和導航/UI問題之間的不同：

　　案例1：網站的兩個重要部分缺乏訪問量。可能的問題根源。

　　IA問題：用戶不理解這兩個部分的命名，或者其命名不能吸引用戶。

　　UI問題：用戶沒有注意到指向這兩個部分的鏈接。

　　案例2：內容頁的“相關鏈接”導航組件無人使用。 可能的問題根源

　　IA問題：“相關鏈接”里面提供的鏈接并不是用戶所感興趣的(分類錯誤)。

　　UI問題：用戶沒有注意到“相關鏈接”組件的存在(可能位置太靠下了，或者被誤認為是廣告)。

　　胡亂猜測問題根源可能帶來很高的代價。如果花錢重新設計了整個界面，結果發現是IA出了問題，那就太悲慘了。反之亦然。時間和資源有限的情況下，找準問題根源具有巨大的價值。接下來我們推薦的方法全都可以快速、遠程實施，甚至無需研究員介入(當然可以自愿介入)。如此快捷有效的測試方法，我們有什么道理不用呢?

　　多種測試幫你找出問題根源

　　結合使用多種測試方法是確定問題真正原因的關鍵。分別針對(a)信息架構和(b)用戶界面進行研究，可以增加正確定位網站問題的幾率。

　　下面將要介紹的4個方法專注不同角度(或IA，或UI)，并給出了定量、定性或兩者皆有的結果。

　　*可用性測試通常是定性的，但是通過一些額外的手段，或使用類似Loop11這樣的工具，也可以產出定量的結果。

　　1. 樹測試

　　樹測試是從IA角度出發的測試方法。用來判斷關鍵任務的相關信息在網站的信息架構中是否可尋。這種測試并不向被測者展示用戶界面。被測者僅僅通過鏈接文字進行導航。

　　此方法可以回答如下問題：

　　類目的命名能否被用戶理解?

　　類目的命名是否準確代表了其內容?

　　網站內容的分類是否以用戶為中心?

　　內容的標題之間是否具有明顯的區分度?

　　導航結構是否過寬或過深，導致信息不易找到?

　　準備工作和測試過程：

　　準備樹測試，你需要創建一棵反映網頁分組和層級的信息架構“樹”(你可以先用電子表格創建好，再粘貼到用于樹測試的應用里)。接下來，你需要創建具體的任務，讓用戶在信息架構中尋找特定的目的地(稱作“終端節點”)。例如，“找到囊括4人家庭并少于每月500美元的健康保險計劃”。測試參與者通過與樹交互來完成任務。

　　結果：

　　測試結果是定量的，包含但不限于：

　　直接成功率：多少參與者不需要在樹中上下反復，就可以找到正確答案?

　　間接成功率：多少參與者雖然找到了正確答案，但是經歷了在樹中上上下下反復游走?

　　首次點擊數據：用戶首先點擊了哪個第一層級類目?首次點擊可以反映出類目命名的合理性。

　　工具：

　　Treejack

　　Treejack 參與者看到的樹測試界面：屏幕頂端列出任務。測試參與者必須通過樹中的標簽進行導航，并找到指定的信息。

　　Treejack 提供的某項任務的樹測試結果，包含了直接成功，間接成功相關數據和所花時間。

　　2. 封閉卡片分類

　　封閉卡片分類是從IA角度出發的測試方法。用來衡量類目命名的有效性。

　　此方法可以回答如下問題：

　　類目的命名能否被用戶理解?

　　類目的命名是否準確代表了其內容?

　　網站內容的分類是否以用戶為中心?

　　內容的標題之間是否具有明顯的區分度?

　　準備工作和測試過程：

　　要實施這類測試，你需要為測試參與者準備“卡片”。這些卡片包含了內容或功能的名稱或描述。接下來，他們將要將這些卡片歸入你定好的類目中。(這種封閉卡片分類與傳統的開發卡片分類不同，后者需要用戶自己創建不同類目并歸類。)

　　結果：

　　測試結果包含定量和定性結論：

　　相似性：相同內容被歸為一組的次數;

　　標準化表格：卡片被歸入預期類目的次數;

　　歸類邏輯：進行卡片分類時，我們建議一定的人工參與，不管是現場還是遠程。這樣你可以采訪用戶為什么把某些內容分為一組?為什么把某些內容歸入某一類目?以及他們如何解讀類目的名字?

　　工具：

　　OptimalSort, UXSort, Usabilitest Card Sorting, UserZoom Card Sorting, UsabilityTools Card Sorting

　　OptimalSort的封閉卡片分類界面：待分類的“卡片”在左側，頁面的主體列出了類目。測試參與者需要將卡片拖拽到類目中，進行分類。

　　OptimalSort提供了封閉卡片測試結果的標準化表格。從這些數據中可以看出多少用戶將卡片歸入某個類目。如果大多數用戶為某張卡片選擇的類目與你的預期不同，那么該重新考慮一下你的信息架構是否合理了。

　　3. 點擊測試

　　點擊測試從UI角度出發，用來發現用戶尋找特定信息或功能時，會點擊界面的哪些部分。點擊測試的一個缺點是，測試過程不是互動的——測試參與者只能看到網站的靜態圖片，然后點擊他們預期可以完成任務的地方。一旦他們點擊了某處，就視作任務完成，可以開始下一項任務了。如果要測試具有交互的元素，需要進行可用性測試。

　　此方法可以用來回答如下問題：

　　哪些導航組件被使用到了?

　　哪些導航組件被無視了?

　　哪些導航組件被刻意避開?

　　準備工作和測試過程：

　　你需要上傳待測頁面的截屏、線框圖或草圖到點擊測試工具里。然后創建任務。測試參與者需要在圖片上點擊那些他們認為可以執行任務的地方。

　　結果：

　　測試結果是一張點擊熱圖，可以幫助你判斷導航設計是否明顯，某些元素是否形成視覺干擾等。

　　工具：

　　Usabilla Visual Survey, Chalkmark

　　Chalkmark呈獻給參與者的點擊測試界面：屏幕頂端列出任務。用戶需要點擊圖片上那些他們認為可以執行任務的地方。

　　Chalkmark的點擊熱圖展示了用戶完成每個任務時都點擊了哪些地方。

　　4.可用性測試

　　可用性測試可以告訴我們用戶要完成某項任務，會如何瀏覽網站(或網站的原型)以及為什么這樣瀏覽。

　　此方法可以用來回答如下問題：

　　用戶如何尋找信息?

　　哪些導航組件被使用到了?

　　哪些導航組件被無視了?

　　哪些導航組件被刻意避開?

　　準備工作和測試過程：

　　你可以在可用性測試中使用原型(紙面原型或可交互的原型)或線上的網站。你需要創建一些任務，讓測試參與者完成這些任務。你需要觀察用戶執行任務的過程，注意他們如何與導航組件交互，以及他們是否無視或者刻意避開了某些導航?可用性測試可以面對面進行，也可以遠程進行。遠程用戶測試可以通過通訊手段進行實時的人工介入，也可以無需測試主持介入，通過在線測試工具完成。

　　標準用戶測試只需要一個用戶和一臺電腦。(如果用紙面原型測試，那就只需要一張紙。)不過如果預算充足，你可以在測試過程中使用眼動追蹤儀，這樣能解答用戶是否看到了任務相關的導航組件這樣的問題。

　　治病的關鍵是診斷正確的病因

　　綜合實施多種測試方法，你會發現有些測試結果是正面的，有些則比較負面。測試結果的不一致恰好證明了分別從IA和UI角度測試的價值。舉個例子，你做了一次封閉卡片測試，發現用戶可以順利地把子類內容歸入你預期的全局導航。而同一環境下的點擊測試則成功率頗低——用戶試圖執行關鍵任務時，只會點擊錯誤的地方。綜合兩個測試的結果，說明了你網站類目命名合理，但是界面布局很有問題。你最好重新設計一下網站的布局外觀。

　　可尋性和可發現性問題會讓人不知所措，在信息不足的情況下做出不經思考的失敗改動。團隊經常沒有多少時間進行研究，更突顯了這四種測試方法的價值——他們不需要多少準備時間，可以同時進行，并且可以遠程實施——如果你想要的話，也可以不讓任何測試人員介入。因此，實施這四種測試中的兩種或多種測試是合理的金錢和時間投資。這樣做可以幫助你深入探索問題的本質原因，并降低采取代價高昂的錯誤解決方案的風險。

（轉載至網絡，僅作為相關資訊的傳播普及目的，如果原作者發現內容的使用不符合本人意愿，請聯系本站作者或客服，將第一時間刪除處理）