網站導覽架構怎麼排？用訪客任務決定頁面層級

從訪客任務安排網站頁面與主次導覽，再用返回路徑、手機選單和紙上找頁測試，檢查重要資訊是否容易找到。

網站導覽真正要回答的問題，是訪客能否從首頁或搜尋入口，走到自己要完成的事。排架構時先整理任務，再把任務配到頁面、導覽層級與下一步；最後用找頁測試確認路徑是否清楚。本文聚焦找頁任務：讓每個重要問題有入口、有承接頁，也有清楚的後續動作。這套方式也適用於新站規劃，或檢查既有頁面是否各自承接清楚任務。

列出訪客主要任務

導覽架構的起點不是公司有哪些部門，而是訪客來此想完成什麼。先從客服問題、業務常被問到的事、站內搜尋詞與表單內容整理需求，再把每項改寫成可觀察的動作，例如確認是否適合、理解流程、比較選項、提出詢問或取得支援。用動詞開頭，能迫使團隊說清楚終點；「認識品牌」太寬，「找到導入前要準備的資料」才有可測試的結果。

不要一開始把所有任務都放進同一張清單。可先按首次到訪、正在評估、已是使用者等情境分組，並為每個任務寫下訪客起點、他缺少的資訊，以及何種結果才算完成。若同一項需求其實包含不同問題，例如先判斷能否使用、再確認如何申請，就拆成前後兩步；若兩句任務最後都要找同一份資訊，才考慮合併。這能避免用內部人的職稱或流程名稱取代訪客語言。

接著做簡單排序：這項任務是否關係到重要決策、是否經常出現、找不到會不會讓人中斷？可先標成優先、次要、偶發，再由客服或業務同事各自補一個實際問法。頻率不必假裝成精確統計；當來源只是少量對話，就註明是初步觀察，後續再用真實查詢修正。排序不是把罕見任務刪掉，而是決定它應在主導覽、次層頁面或頁尾出現。

例如假設一間提供設備維護的公司，訪客可能要先查服務區域、再判斷故障是否承接，最後聯絡安排。這三件事有順序，不能只用「公司資訊」一頁包辦。先畫出任務順序，再確認每一步的答案由哪頁提供；如果團隊對任務說法不一致，先回看訪客原話，而不是趕著加一個選單項目。如此得到的清單才會直接指向頁面層級。

配對頁面與問題

任務清單有了，接著把訪客的問題、需要的證據、承載頁面、下一步逐列對起來。先問人必須知道什麼才能繼續，再看現有頁面能否清楚回答。若答案跨了多種意圖，拆頁或建立明確分段；若一個頁面只換標題卻提供同一份資訊，就不必製造重複頁。盤點時記錄目前網址、負責更新的人與缺失內容，避免只新增頁面、不處理舊入口。

各欄若填不出訪客問題，通常代表命名來自內部分工，而非任務。檢查每頁開頭是否指出適用對象、能解決的事和如何往下走；要做比較，就提供可對照的條件，不要藏在長篇介紹裡。需要行動時，按鈕或連結要接到相符步驟；例如「了解內容」連到說明，「提出詢問」連到可完成詢問的位置，別讓不同意圖共用同一個含糊名稱。

完成對照後，檢查缺口、重複和無承接三種情況。缺口是重要任務找不到任何頁面；重複是多頁用不同名稱回答同一問題；無承接是頁面有內容，卻沒有合理下一步。選擇先補哪一項時，以任務重要性和訪客是否會中斷為準，而非看哪個部門最想要曝光。頁面負責人也要能確認內容更新方式與所需證據，否則結構再好也會被過時資訊削弱。可把每頁的主問題先寫在卡片上，請沒參與規劃的人只讀標題，說出預期答案；若答案落差很大，先修正頁面定位，再安排內容。

安排主次導覽

主導覽要讓訪客辨認主要任務的入口，不必重現公司組織圖。先把高優先任務歸成少數幾組，再用訪客看得懂的詞命名；如果兩個選項看起來都能回答同一問題，代表分類邊界還不清楚。主選單放最常見、最重要或必須快速找到的入口，次層才承接細分主題、支援內容與低頻資訊。頁面層級應反映任務關係，不應只是誰負責哪個部門。

用假設的工作室網站為例，訪客主要想了解服務、看作品、詢問合作，次要任務是查看團隊背景與常見問題。可把前三者放在主導覽，背景和問答放進相關頁面的次層或頁尾；若「常見問題」涵蓋合作前準備，就在合作說明中也放一條清楚連結。這不是唯一正確的排列，應以測試結果決定，而非照抄別人的選單。

每個標籤都要通過兩個檢查：第一次來的人能否預測點進去會看到什麼？兩個選項並列時，能否說出它們的差別？抽象字詞如「探索」「資源」若涵蓋很多內容，可改成描述內容或任務的名稱；同時避免把不同目的塞進一個「更多」入口。排序可讓高優先任務靠前，但不要只因內部曝光需求而把低相關頁面擠到前方。

主選單以外，也要安排頁尾、麵包屑、站內搜尋和頁面內連結的分工。頁尾可放聯絡、政策或低頻入口，麵包屑呈現目前位置，頁內連結則接續當前任務。重要頁面可有不只一條抵達路徑，但每個入口都要符合當下情境；例如訪客讀完服務說明後，下一步可以是查看流程，而不是被帶回無關的公司介紹。畫出層級圖後，逐一說明每個入口為何放在該處。

檢查返回與深層路徑

訪客不只需要找到頁面，也需要知道自己位於哪裡，以及怎麼回到上一層。把常見路徑從入口一路畫到任務完成，再反向檢查每一步：頁面標題是否說明主題、導覽是否標示目前區域、返回連結是否回到有用的分類？如果只靠瀏覽器的上一頁才能退回列表，或頁面跳到新主題後失去原本脈絡，就要補上站內路徑。

測試時選一條真實情境，例如從搜尋結果進入某篇教學，接著要找相關服務說明，再回到同類內容。照訪客的順序點擊，不要預設他先看首頁；記錄每一步是否看得懂入口名稱、是否保留原來的篩選或分類，以及返回後是否仍能接續閱讀。若教學和服務屬不同區域，提供清楚的相關連結即可，不必把每條路徑硬塞進層級樹。

深層頁面要特別確認沒有孤島。孤島可能仍能由搜尋抵達，卻沒有從主題分類、相關內容或導覽連到它。用網站清單列出重要頁，檢查每頁至少有一個合理的站內入口，也確認舊連結、重新命名後的路徑與頁面不存在時的替代方式。不要為了縮短層級而把所有內容平鋪在首頁；找得到的關鍵是清楚的線索和一致的分類，不是單純少點幾次。

返回路徑也要配合內容類型。文章可連回主題分類，服務細節可連回總覽，流程步驟可提供前後順序；如果某頁屬於暫時性活動或外部工具，需說明回到網站的方式。最後挑一個高優先任務，請不了解架構的人只靠頁面線索往返一次。若他反覆回首頁重找，先查看命名和上下文連結，再決定是否真的需要改層級。

檢視手機選單層級

手機畫面空間有限，不能只把桌面選單縮小後照搬。先在小螢幕上列出最重要任務，再看選單展開後是否能快速掃讀；低頻項目可收在次層，但詢問、支援或其他關鍵入口不應藏在多次展開之後。若桌面有多欄或懸停選單，手機需改用明確的展開與收合方式，並讓訪客看得出哪些項目還有下一層。

逐個操作主要流程：打開選單、展開分類、進入目標頁、返回，再換另一項任務。觀察選單是否因跳頁突然關閉而讓人失去位置、返回時是否保留展開狀態，以及選項太長時是否被截斷。文字要能清楚區分相近頁面，互動區域也應容易點選；不要只靠顏色、圖示或懸停提示傳達重要意思。鍵盤操作、焦點順序和螢幕閱讀器名稱亦應能辨認目前控制項。

假設訪客用手機想聯絡網站上的服務提供者，可從首頁直接打開導覽，找詢問入口並到達表單，再確認返回時能否回到服務說明。若必須先猜「關於」或展開多個不相干分類，選單名稱和順序就需要調整。可以把聯絡入口同時放在頁首可見區與相關說明頁，但要確認兩處指向一致，並且在不同頁面都可辨認。

手機選單的深度要以訪客理解成本判斷，而不是追求看起來簡短。每多一層，就確認是否真的有一組清楚的子任務，且父層頁面仍有用途；如果父層只是空白標題，應改為可瀏覽的分類頁或整理成直接入口。最後在多個頁型上實際展開、收合和返回，檢查固定頁首是否遮住內容、長頁捲動後能否重新打開選單，並在改動後重跑相同任務。

做紙上找頁測試

紙上測試能在改版前檢查分類和名稱，不需先完成視覺設計。把主導覽、次層與重要頁面寫在卡片上，按目前架構排好，再給測試者一個具體情境，例如「你想知道是否能預約某種服務，會先選哪一項？」請對方指出第一個選擇和預期看到的內容；只問任務，不提示答案，也不要在他猶豫時代替解釋。

過程記錄第一個選擇、走過的卡片、停頓、回頭和用自己的話描述的頁面內容。若有人先選到別的分類，先檢查名稱、內容切分和任務是否混合。若他們選對分類卻找不到細節，問題可能在第二層；若卡片上根本沒有能承接任務的頁面，才是內容缺口。區分原因後再改，避免只換詞卻留下錯誤層級。

先挑幾個高優先、彼此不同的任務，讓不同背景的人各自完成；這是找出誤解的探索，不要把少數人的結果說成全體使用者的統計。每輪只改一類問題，例如先調整標籤，再重做相同情境，才看得出改動有沒有幫助。若同一張卡片被理解成兩種意思，就改成更具體的訪客用語；如果某頁常被誤放在其他類別，則檢查它和相鄰頁的任務差異。

測試後先整理最常讓人走錯或中斷的地方，依任務重要性、影響範圍和修正成本排次序。把結果寫成「任務、原路徑、卡住原因、調整、重測觀察」，交給負責網站內容的人執行；改完後回到真實手機和桌面頁面再走一次，因紙上分類正確不代表實際入口一定清楚。你可以今天先畫出一張導覽草圖，再用三個不提示答案的任務測試；若想把規劃結果整理成可交接的工作清單，也可前往 ZhenheAI 官網 了解品牌目前資訊。