總結：遵循這些提示可以有效地評估一個網站的導航層級，并避免常見的設計錯誤。
在網站設計中，重復的信息類別和令人疑惑的命名是兩種最常見的設計問題。幸運的是，有一些快速和有效的技術可以用來創建對用戶有意義的類別和命名。
卡片分類法也許是最著名的技術了，向用戶提供一組有代表性的內容項，讓用戶按照自己認為合適的方式分組并命名。卡片分類法在理解用戶如何思考方面有著難以估量的價值，但是它不一定會產生你應該遵循的最合適的分類。比如說，卡片分類的參與者常常會創建一個通用的分類去放置那些放在其他地方都不合適的項目，這是可以理解的，但是如果你真的把一個“其他”類別放在菜單中，同樣的這群用戶卻會像躲避瘟疫一樣避免去點擊它。（眾所周知，網站訪客一般會避免點擊那些表意模糊的類別，因為他們非常合理地懷疑他們需要做很多工作去過濾其中的內容。）
為了得到最好的結果，在卡片分類之后應該做一個樹形圖測試來評估備選的菜單結構。
定義：樹形圖測試通過讓用戶在樹形圖中尋找在哪個位置能夠完成給定的任務，以此評估一個層級分類結構，也就是一個樹形圖。
在卡片分類之后使用樹形圖測試會非常有用，因為：
- 它通過使用類似于可用性測試中的任務來觀察一個層級結構在真實場景中的表現，從而對其進行評估；
- 它可以在開始設計頁面布局或者導航菜單之前進行，因此可以對菜單類別和命名進行低成本的探索和調整。
要執行一場樹形圖測試，你不需要繪制任何線框圖或者寫任何內容。你只需要準備兩種東西：樹形圖，即層級菜單，以及任務，即用于向研究參與者解釋他們需要找些什么的說明文字。
定義樹形圖
你的樹形圖應該包含你的所有主要內容分類，以及它們的所有子分類。即使你只對樹形圖的某個特定部分的測試感興趣，也不應該排除掉其他部分，因為這隱含了用戶知道應該選擇哪個部分的假設。比如說，如果你的網站有一個“產品”分類和一個“服務”分類，而你只選擇測試“產品”樹形圖，你就無法發現你的用戶是否理解這兩個類別之間的區別。
你的樹形圖可能需要3個、4個甚至5個層級之深，取決于你最感興趣的是層級結構的哪一部分。樹形圖應該包含到你想要測試的子分類的最低層級。每一個子分類都應該提供其包含的所有選項，以便觀察到用戶的真實行為。用戶通常會通過與周圍選項的比較來評估一個鏈接的標簽名。比如說，對歷史感興趣的用戶可能會嘗試點擊一個叫做“文化”的分類——除非同時有一個叫做“歷史資源”的選項。
競爭性樹形圖測試：命名還是位置
如果你在考慮同個樹形分類的不同命名，你可能想要測試不同的樹形圖以便比較這些名稱的表現。這種測試用Userzoom的樹形圖測試工具就很容易做，可以把參與者隨機分配到不同版本的樹形圖中，類似于真實網站中的A/B測試。如果你測試多個樹形圖，要避免在同一個會話中向同一個用戶展示兩個不同的樹形圖——用戶在于第二個樹形圖交互時的行為會受到第一個的影響而產生偏差。
如果只是想要比較命名相同而位置不同的兩個方案——比如說“土豆”應該放在“水果”還是“蔬菜”類別下，沒有必要準備和測試一個單獨的樹形圖。不需要對兩種位置的樹形圖都進行測試，你可以只測試一個樹形圖然后比較有多少人點擊了水果以及有多少人點擊了蔬菜。（如果用戶兩個都點擊了，也可以區分他們首先點擊的是哪個類別。）
準備測試：工具和格式
你可以使用一個紙面原型（或者認可可點擊的原型工具）進行樹形圖測試，但是一個專門為樹形圖測試而設計的工具將會極大地促進結果分析過程，值得一試。Userzoom和Treejack都是不錯的工具。
在電子表格中準備好你的樹形圖，你可以方便地查看和編輯，然后將整個層級復制粘貼到你的樹形圖測試工具中。電子表格應該格式化，首頁應該在第一列的第一個單元格，然后將較低的層級按列從左到右列出。確保每行都只展示一個類別，這樣子你導入這個層級的時候才能被正確解析。
將你的層級粘貼到測試工具中之后，這些類別會被解析并用于自動生成一個可點擊的菜單層級，在這個菜單層級中每一個類別都可以展開并展示相關的子類別。
上圖是Treejack根據電子表格自動生成的可點擊的菜單，包含了所有類別和子類別。
樹形圖測試任務
要求用戶完成的任務跟樹形圖本身一樣重要。首先你需要決定目標類別和命名。理想情況下應該包含指向以下目標的任務：
- 網站的關鍵目標和用戶任務，比如尋找你們最重要的產品（首要的導航任務的成功率可以作為次要任務的對比基線，以及未來的測試中的參考值）。
- 潛在的問題區域，比如利益相關者或者卡片分類的參與者所倡議的新類別。
命名或者位置對比——同個分類的不同命名或位置。對于你寫的每一個任務，都應該定義正確的回答是什么，也就是這個信息實際上位于樹形圖的哪個位置。這個信息讓測試功能能夠自動計算出每個任務的成功率。
任務措辭
每一個任務都應該通過要求用戶找到某個類別包含的某個內容來測試一個類別。正如可用性測試中的任務，樹形圖測試任務的說明應該避免向用戶提示正確答案。有時候可以通過描述一個場景和動機來避免這種暗示，但是仍然要注意用戶不一定會認真讀說明，如果要閱讀一個冗長的故事他們可能會錯過重要的細節。
舉個栗子，要測試墨西哥州政府網站上的一個叫做“創業”的類別時，可能有以下幾種不同的措辭：
- 尋找關于創業的信息。
- 你明年要搬到圣達菲，你到了之后想要通過開創一個副業提供草坪護理服務，以此增加自己的收入。尋找你可能需要遵循的條例。
- 你在考慮開創一個草坪護理服務。看看網站上是否有可以幫助你開啟項目的資源。
第一種表述直接使用了“創業”這個詞語，已經把答案呈現出來了；而第二種表述很長并且包含了一些無關的信息，用戶沒有認真看的話可能會誤以為那是任務的重點。第三種表述能夠同時避免提示答案和誤導性的細節。
樹形圖測試的局限
樹形圖測試通常是作為一個遠程的、非調節的研究。在招募到有代表性的用戶之后，可以簡單地向他們發送一個鏈接，然后測試工具就會引導用戶使用自己的電腦完成任務。測試工具比人類更擅長關注用戶具體點擊了哪個類別。
但是，這種形式不能捕捉到用戶行為的完整情境（比如用戶在做一個任務時的評論）并且你無法根據用戶的情況問問題。
為了最小化這種影響，可以在正式收集數據之前進行至少幾個調節的預測試。在這些調節的測試中可以確保任務的措辭是可理解的，并且有機會發現在定量數據中很難發現的細微差別。比如，在一個最近的樹形圖測試中，我們發現在預測試中很多用戶在前一半任務中都避開了一個特定的類別，因為它的命名太寬泛了，用戶擔心其中的內容太多。這個趨勢在定量結果中無法觀測到，因為任務的順序會進行隨機，但是當你能夠親眼看到用戶在一個接著一個的任務中忽略了一個很明顯的選項時，這件事情就很明顯了。僅僅是這個洞見就使得預測試的一天值得花費。
你也可以通過在樹形圖測試之后添加一個簡短的問卷，可以部分地彌補無法在測試之后詢問問題的損失。比起要求用戶回想他們覺得令人困惑的分類，向他們提供一個類別列表并讓他們檢查哪些比較難以理解，可能會更好一些。可以在最后添加一個開放性問題，讓用戶分享更多的評論和反饋，以發現從點擊記錄中無法明顯看出的非預期的假設和誤解。
結論
樹形圖測試專注于評估分類標簽。這既是它的巨大優勢，也是一個明顯的弱點。因為用戶交互的菜單完全沒有視覺設計和內容，體驗會與跟完整設計的交互明顯不同。比如，一個多欄下拉菜單（mega menus）提供的瀏覽體驗就會跟樹形圖測試中的很不一樣，因為它會同事呈現多個子類別中的內容。
但是，即使是這些固有的缺陷也通常能夠通過仔細的數據分析得以避免或弱化——比如，對于多欄下拉菜單來說，我們可以關注用戶是否選擇了正確的一級類別，而不是關注人物的成功率。
總之，這些局限都是為了能在設計過程的早期快速迭代和評估信息架構的關鍵結構調整而需要付出的小小代價。你可以測試一個全新的樹形圖，僅僅通過編輯你的電子表格——完全不需要設計或者編碼。
翻譯自：Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories
