如何執行以任務為核心的網站資訊架構稽核

在核准網站改版或內容移轉前，先以具代表性的使用者任務為單位，逐一追查外部入口、導覽、標籤、頁面分組、情境連結與站內搜尋，再用合適的研究方法驗證不確定路徑；本指南提供可追溯的工作表、失敗分類、優先排序與後續複測原則，協助團隊依據實際證據選擇最小可行修正，並判斷何時才有理由啟動全面重整。

WebChorus Editorial Team2026年7月25日10 分鐘閱讀

資訊架構
網站稽核
使用者研究
導覽測試
網站可尋性
網站治理

面對網站改版或移轉提案，先別從重畫網站地圖開始。選出一項對使用者與組織都重要的任務，定義完成結果，再追查使用者從外部到站、瀏覽、情境連結與站內搜尋抵達結果的每一條合理路徑。擁擠的選單、高離站率或「很難找」的抱怨只能指出值得調查之處；若沒有任務層級的證據，團隊很容易把缺少內容、標籤不清、搜尋結果不佳或控制項難用，誤判成整站結構失敗。

先掌握這五項原則

先稽核具代表性的任務及其合理路徑，再檢查選單或提議新的網站地圖。
把分析資料、搜尋紀錄、客服需求與專家檢查視為待解讀的訊號，不當成原因已明的結論。
分組與類別語言用卡片分類驗證，階層與標籤用樹狀測試驗證，完整網站路徑則用任務式可用性測試驗證。
先判定是內容涵蓋、入口、標籤、分組、定位、連結、搜尋、一致性或互動問題，再選擇修法。
採用證據支持的最小修正並複測受影響任務，只有局部修補無法處理反覆出現的結構性失敗時，才升級為全面改版。

資訊架構稽核應先回答哪一項決策？

稽核應先服務一項有邊界的決策，例如修復某個內容區、調整一組標籤、準備內容移轉，或判斷現有證據是否足以支持全面重整。資訊架構涵蓋內容組織、標籤與導覽，目的是協助人們找到資訊、理解目前位置與可用選項，並完成預期任務；因此稽核的核心不是評鑑網站看起來是否整齊，而是判斷指定路徑系統能否支援指定任務。

把適用範圍寫進稽核簡報：包含哪些受眾、目標、起始情境、頁面類型、裝置、語系、權限與旅程狀態，也要寫明排除項目。結論只能套用在這些情境，不能代表抽象的「平均使用者」。任務式資訊架構稽核也不等同於內容盤點、技術搜尋引擎最佳化稽核、完整無障礙符合性評估或改版設計；若發現相鄰領域的問題，應另立工作項目處理。

已知事實：可核對的網站狀態、內容與營運條件。
行為觀察：實際看見使用者採取的步驟、錯誤與復原。
專家檢查：研究人員依準則辨識的疑似缺陷。
未驗證假設：利害關係人推測的需求、原因或解法。

如何從證據建立具代表性的任務集？

一名研究人員坐在寬大的辦公桌前，查看分組擺放的空白卡片、淺色便條與模糊列印資料。

具代表性的任務集應以使用者想達成的結果為主，並為每項任務保留證據來源、適用受眾、觸發情境與完成條件。任務敘述要採用使用者認得的語言，但不能洩漏目的頁標籤或預設的導覽答案；與其寫「到服務中心下載申請表」，更適合描述需要完成的結果，讓受測者自行判斷從哪裡開始以及何時算完成。

候選任務可來自訪談、觀察、既有研究、分析資料、站內搜尋紀錄、客服需求、意見回饋，以及直接接觸使用者的第一線人員。這些來源的證據強度不同：流量、離站與搜尋字詞能指出該追問的位置，卻不能單獨證明使用者意圖、問題成因或正確修法；內部意見若沒有使用者證據支持，就應明確標示為假設。Digital.gov 記錄的研究也示範了從先前研究建立實際任務並在測試前檢查涵蓋面的做法。

納入高頻任務，也納入後果重大、特別困難或長期未被妥善服務的任務。
記錄任務所屬受眾、觸發事件，以及可能從外部頁面、區段頁或登入區開始的情境。
定義完成所需的內容、操作或確認狀態，避免只把「抵達某頁」當成成功。
保存原始研究、查詢、客服紀錄或假設的來源，方便日後追溯與更新。

任務對路徑工作表應記錄哪些內容？

兩名同事在鋪滿模糊頁面縮圖的桌上規劃路線，一人放置圓形標記，另一人用筆記錄觀察結果。

任務對路徑工作表應把一項有來源的任務，連到預期結果、合理路徑、檢查過的提示、實際觀察、失敗診斷與後續複測。不要假設所有人都從首頁出發，也不要只記錄團隊熟悉的成功路線；同一任務可能從搜尋引擎帶入頁、區段首頁、登入後頁面、內容中的相關連結或站內搜尋開始，而不同權限與旅程狀態又可能改變可用選項。

在每個決策點，記錄畫面上看得到的提示、它建立的期待、實際抵達處，以及走錯後能否辨認問題並恢復。WCAG 2.2 成功準則 2．4．5 要求頁面集合中的頁面具有不只一種定位方式，但流程結果或流程步驟屬於例外；相關連結、網站地圖、搜尋與完整導覽都是文件列舉的做法。這項檢查可提醒團隊查看替代路徑，卻不能取代完整的無障礙評估。

先登錄任務、受眾、觸發情境、成功結果與證據來源。
再列出各起點的瀏覽、情境連結及搜尋路徑。
逐點記下提示、期待、目的地、行為與證據強度。
完成失敗分類、最小修正、負責人與複測安排。

任務式資訊架構稽核不問網站地圖是否整齊，而問人們能否循合理路徑達成需要的結果，並留下足以採取行動的證據。

任務對路徑工作表的四組核心欄位
任務、受眾、觸發情境、結果與來源證據	起始情境、合理路徑與檢查提示	觀察行為、選用指標、失敗模式與證據強度	最小修正、負責人與複測
用結果語言寫任務，標示適用受眾、觸發時機、完成條件及研究來源。	列出外部到站、瀏覽、情境連結、站內搜尋與權限狀態，逐點記錄可見提示。	記下完成、協助、錯誤、繞路、返回、查詢改寫、信心與參與者理由，再判定失敗類型。	提出證據支持的最小變更，指定決策者與執行者，寫明要重做的任務及路徑。
若目前只有內部主張，清楚標為假設，不與已觀察的使用者需求混列。	若存在多條有效路徑，分別保留，不因其中一條成功就省略其他情境。	將專家疑慮與使用者行為分欄，避免把推測誤寫成已發生的失敗。	修正後回到同一成功條件比較，不以發布完成或網站地圖更新取代成效判斷。

如何檢查完整路徑，而不是只看選單？

一名男子坐在書桌前，比對桌上型螢幕與平板電腦上的同一模糊頁面，桌面鋪著標有路線的列印資料。

完整路徑檢查必須從實際起點一路走到所需內容、操作與確認狀態，沿途查看外部進站頁、全站及區域導覽、索引頁、頁面分組、標題、麵包屑或其他位置提示、情境連結、站內搜尋與最終目的地。每到一站都要問：使用者能否知道自己在哪一層、目前有哪些下一步、目的頁是否兌現前一個提示的承諾，以及無效選擇後是否容易回復。

標籤要依它在當下情境建立的期待評估。Microsoft 建議從使用者觀點、常見任務與心智模型規劃導覽，並讓標籤準確、熟悉、精簡、可掃讀且能與鄰近選項區分；WCAG 2.2 成功準則 2．4．6 也要求已提供的標題與標籤描述主題或用途。對重複導覽，成功準則 3．2．3 關注的是相對順序的一致性，並不禁止局部或次要導覽。

在桌機與手機、公開頁與登入區、不同語系或權限間，重做會因情境改變的關鍵任務。
比較同一功能在不同頁面上的名稱、位置、順序與行為，找出使用者無法預期的變化。
檢查搜尋查詢、結果相關性、摘要提示、查詢改寫、目的地信心與最後是否完成任務。
不要因使用者選擇搜尋就判定導覽失敗；搜尋可能是偏好路徑，問題須由完整行為判讀。

每一條不確定路徑該用哪種研究方法驗證？

兩名女子隔著白色桌子面對面坐著，一人操作螢幕模糊的筆記型電腦，另一人拿著筆與便條傾聽。

驗證方法應依尚未回答的證據問題選擇，而不是把每一種研究都排進固定流程。專家檢查與既有行為資料適合定位疑似缺陷，但不能把檢查者的推測寫成已觀察到的使用者失敗；先在工作表上標明不確定性，再選擇能隔離該問題的方法，才能避免用錯證據回答錯問題。

如果不確定使用者如何替內容分組或會用什麼類別語言，採用卡片分類；它不驗證完整網站路徑。
如果要隔離階層與標籤是否讓人找到目的地，採用樹狀測試；它會排除大部分實際頁面與控制項影響。
如果問題跨越畫面導覽、頁面提示、情境連結、搜尋、錯誤復原或任務完成，採用任務式可用性測試。
如果已有明確路徑疑慮但缺少行為證據，讓相關使用者從真實起點執行任務並說明判斷理由。

NIST 將可用性測試描述為由具代表性的使用者執行具代表性的任務，證據可包含完成、錯誤、時間、質性意見與滿意度。實際稽核不必把所有項目做成固定計分表；應挑選能支援決策的觀察，例如是否需要協助、走錯幾次、是否返回、如何改寫搜尋字詞、對目的地有無信心，以及參與者為何選擇該路徑。分歧路徑不一定是失敗，但其理由可能揭露含糊分組或標籤。

如何把發現轉成局部修正，或有根據的改版決策？

四名同事圍坐在會議桌旁，查看成排的空白卡片，以及由紅色、黃色與藍色圓形標記組成的三個分組。

先準確分類失敗，再依可見的決策條件選擇最小修正。若每個症狀都被統稱為「導覽問題」，缺少內容會被拿去改選單，搜尋排序不佳會被拿去重組網站地圖，互動控制失效則可能被誤認為階層太深。分類不是為了製造一個總分，而是讓每項發現都能連回任務、證據、修法、負責人及複測。

涵蓋：所需內容、操作或狀態不存在或不完整。
入口：常見起始情境沒有合理的下一條路。
標籤：提示未描述目的地，或用語陌生、含糊、不一致。
分組：內容所在位置不符預期，或類別重疊難以區辨。
定位：使用者不清楚所在位置、層級或下一步。
情境連結：需要採取下一步之處缺少相關路徑。
搜尋：相關查詢產生缺漏、誤導或難以解讀的結果。
一致性：重複功能或導覽的名稱、順序或行為改變。
互動：結構本身合理，但實際控制項或版面妨礙使用。

排序時公開任務重要性、受影響受眾、觀察到的失敗頻率、後果、證據強度及修復相依性，不要把判斷藏進一個宣稱通用的加權分數。修法可以是補正內容、調整標籤或連結、重新分組、改善搜尋、重整單一區段，或在必要時進行更廣泛的結構改版。每一項建議都要說明為何是目前證據足以支持的最小介入。

發布修正並不等於任務已改善；應讓相關代表性使用者重做受影響的任務與路徑，再依原先決策需要觀察完成、協助、錯誤、時間及理由。只有重要任務在相關情境中反覆出現、有觀察證據支持且難以局部修復的結構性失敗，才足以形成全面重整的理由。若研究設計或結構取捨超出團隊能力，應找有經驗的資訊架構師或使用者研究員；若結果涉及無障礙疑慮，則另請合格專業人員執行適當的符合性評估，因為本稽核及所選 WCAG 檢查不能證明整站符合規範。