如何進行以任務為本的網站資訊架構審核

在重畫網站地圖或批准全面改版前，先揀一項對業務及用戶都重要的任務，追查人們由不同起點到達所需內容或完成行動的每條合理路線。擠迫的選單、高離開率頁面和「很難找」的投訴只表示值得調查；它們未能說明問題究竟是內容欠缺、標籤含糊、分組不合預期、情境連結不足、搜尋結果欠佳，還是控制本身難以操作。

以任務為本的資訊架構審核，把可完成的用戶結果而非頁面數量或網站地圖整齊程度當作分析單位。團隊為任務訂明成功結果及證據來源，列出外部入口、瀏覽、情境連結和站內搜尋路線，再把檢查發現、實際觀察與未驗證假設分開記錄。這樣才可選擇有證據支持的最小修正，並在投入遷移或改版預算前重測真正重要的旅程。

審核應該為哪一項決定提供依據？

審核首先要服務一項有邊界的決定，例如修補某個服務部分、改動標籤、準備內容遷移，或判斷證據是否足以支持較廣泛的改版。資訊架構涵蓋內容組織、標籤及導覽，作用是讓人找到所需資料、理解所在位置與可選方向，並完成預定任務。決定一旦清楚，團隊才知道要收集多強的證據，以及哪些問題其實不在本次工作內。

• 受眾：包括哪些客戶、會員、合作夥伴或內部角色。
• 情境：任務目標、觸發原因、起點、裝置、語言版本及旅程狀態。
• 系統範圍：公開頁面、已登入專區、搜尋、相關入口及指定頁面類型。
• 證據標記：已知事實、行為觀察、專家檢查發現及未測試假設分欄記錄。

任務式資訊架構審核評估的是現有路線系統能否支援指定任務；它並非內容清單、技術搜尋器優化審核、完整無障礙合規評估或預先決定方向的改版工程。結論也只適用於已納入的用戶、頁面、權限、裝置和語言情境，不能包裝成對「一般用戶」或整個網站的無條件判斷。這項限制應寫進審核摘要，免得局部發現被放大成全站結論。

怎樣從證據建立具代表性的任務組合？

具代表性的任務組合要以用戶想取得的結果來寫，並為每項任務保留清楚來源。不要在題目中洩露網站現有標籤或預設目的地，例如不要叫參加者「前往服務支援」，而應描述需要解決的事情及完成條件。GOV.UK的研究指引建議先了解人們想做甚麼、目前怎樣做、遇到甚麼問題，以及真正需要甚麼結果；這個次序可避免團隊把現有網站結構誤當成用戶需要。

分析數據、站內搜尋字詞、客服個案、既有研究、訪談、觀察及直接接觸用戶的同事都可提供證據；不代表用戶的內部意見仍是待驗證假設。這些資料是找問題的入口，不是意圖、成因或修正方案的獨立證明。Digital.gov記錄的一項資訊架構研究，便由先前研究整理貼近實況的任務情境，並在測試前覆核涵蓋範圍。

• 任務結果：要找到的內容、作出的決定或完成的行動。
• 人物與觸發：誰在甚麼情況下需要處理這件事。
• 可能起點：外部落地頁、部門頁、登入區、相關內容或站內搜尋。
• 完成條件：甚麼可觀察結果才算任務完成，而非只到達某頁。
• 證據來源：研究、數據或營運紀錄的日期、範圍及限制。

任務組合不應只收錄流量最高或最容易完成的事項，也要涵蓋後果重大、已知困難及服務不足的需要。實際比例應按本次決策、受眾差異與可用證據訂定，而不是套用一個固定數目。若任務只來自管理層工作坊，先把它們列為候選假設；待搜尋紀錄、客服個案、訪談或觀察提供支持後，才提升為代表用戶需要的審核任務。

任務至路線工作表需要記錄甚麼？

工作表要把每項有證據支持的任務，連接至成功結果、合理路線、沿途提示、觀察行為、故障分類及重測安排。先並列任務的預定結果與實際目的地，再逐一記下起點和經過的決策點。同一任務可能由搜尋器帶來的落地頁、部門首頁、已登入專區、相關內容連結或站內搜尋開始，不能預設人人先到主頁。

每個決策點都要記錄用戶看見的字詞或視覺提示、提示建立的預期、按下後到達哪裏，以及走錯後能否辨認問題和返回有效路線。瀏覽路線、情境連結和搜尋路線要分開追查；某一路徑成功，不代表其他常見起點同樣可用。搜尋本身可以是有效而且有人偏好的替代路線，使用搜尋不等於導覽失敗。

WCAG 2.2成功準則2．4．5要求頁面集內的頁面有多於一種定位方法，但屬於流程結果或流程步驟的頁面除外；相關連結、網站地圖、搜尋及完整導覽均屬文件列出的做法。這項準則支持檢查替代路線，卻不是「每頁必須有相同入口」的規則，也不能單憑一次路線檢查宣稱網站已符合全部無障礙要求。

任務式資訊架構審核不問網站地圖是否整齊，而問人能否沿真實路線抵達所需結果，並留下可採取行動的證據。

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

完整路線檢查要由真實入口走到所需內容或行動，沿途檢視所有會改變理解及選擇的部分。不要停在全站選單：外部落地頁、全站與局部導覽、內容樞紐、頁面分組、標題、麵包屑或其他位置提示、情境連結、站內搜尋結果，以及最後能否完成事情，都屬同一條任務路線。目的地有頁面但資料殘缺，應記作內容覆蓋問題，而非自動歸咎導覽。

• 入口承諾：落地頁提供的線索是否足以開始任務。
• 選擇承諾：標籤是否讓人合理預期下一個目的地。
• 位置理解：人能否知道自己在哪一層、可做甚麼及下一步在哪裏。
• 錯誤回復：選錯後能否辨認、返回並嘗試另一條合理路線。
• 目的地完成：內容、狀態或控制是否真的讓任務完結。

Microsoft的資訊架構指引建議按用戶觀點、常見任務及心智模式規劃導覽，並把準確、熟悉、簡潔、容易掃讀及可與相鄰選項區分列為標籤特質。WCAG 2.2成功準則2．4．6則要求已提供的標題及標籤描述其主題或用途，從而協助理解組織及尋找資料。短字不一定清楚；標籤仍要放回相鄰選項、起點及目的地之中判斷。

成功準則3．2．3針對的是重複導覽機制的相對次序：除非由用戶觸發改變，次序應保持一致；它沒有禁止局部或次級導覽。裝置、語言版本、權限及任務狀態如會改變可用入口或控制，就要重走重要任務。同樣地，見到用戶選擇搜尋時，先查詢字詞改寫、結果相關性、目的地信心及最終完成情況，才判斷問題在導覽、搜尋或內容。

哪種研究方法最適合驗證不確定路線？

驗證方法要按尚未解答的證據問題選擇，而不是把所有方法順序做一次。專家檢查及既有數據可先找出疑點，但在真人測試前，只能記作檢查發現或假設，不能寫成已觀察到的用戶失敗。先問團隊究竟不確定內容應如何分組、層級與標籤是否可尋、還是已呈現網站的整條路線能否使用，再揀相應方法。

• 卡片分類：研究參加者預期怎樣分組內容，以及會用甚麼類別語言。
• 樹狀測試：抽離頁面設計，集中測試層級與標籤能否帶人找到目的地。
• 任務式可用性測試：觀察真實頁面提示、控制、情境連結、搜尋、回復及完成。
• 專家檢查與行為資料：定位值得驗證的疑點，並為研究設計提供脈絡。

Digital.gov把卡片分類描述為了解參加者如何組織內容的方法；在開放式分類中，參加者亦會為自己建立的組別命名。它不會驗證已呈現網站中的完整路線。樹狀測試可抽離頁面視覺設計，集中檢查層級與標籤能否帶人到目的地，並揭示含糊類別；代價是看不到大部分真實介面，因此不能取代完整網站的任務測試。

NIST把可用性測試描述為由具代表性的用戶執行具代表性的任務，證據可以包括完成情況、錯誤、時間、質性意見及滿意程度。審核毋須把所有量度變成固定計分表；應按決策選擇求助、錯誤轉向、返回、搜尋改寫、目的地信心及參加者推理等觀察。Digital.gov的個案亦顯示，參加者採用的分歧路線及其解釋，即使最後有人到達正確目的地，仍可暴露含糊的分組或標籤。

怎樣把發現變成局部修正或有理據的改版？

先準確分類故障，再選擇有證據支持的最小介入。若目的地沒有必要資料，是內容覆蓋問題；若常見起點沒有合理方向，是入口問題；提示承諾與目的地不符屬標籤問題；內容落在意料之外或類別重疊屬分組問題。這個分類可防止團隊把每個症狀都寫成「導覽很差」，更可把修正交給真正有能力處理的內容、搜尋、設計或平台負責人。

• 覆蓋：所需內容、行動或狀態不存在或不完整。
• 入口：常見起點沒有合理路線。
• 標籤：提示不準確、不熟悉或前後不一致。
• 分組：目的地位置不合預期，或類別界線含糊。
• 定位：人不知道身處何處、到了哪一層或下一步在哪裏。
• 情境連結：需要下一步的地方沒有相關路線。
• 搜尋：相關查詢得到缺漏、誤導或難以判讀的結果。
• 一致性：重複導覽或功能的名稱、次序或行為無故改變。
• 互動：結構合理，但已呈現的控制或頁面設計妨礙使用。

排序時把任務重要性、受影響受眾、觀察到的失敗頻率、後果、證據強度及修正依賴逐項攤開討論。不要把判斷藏進一個貌似客觀的通用加權分數；資料並沒有提供可適用於所有網站的點擊數、成功率、樣本量或改版門檻。工作表應保留每項輸入、尚存不確定性及決策理由，讓內容修正、標籤或連結修補、重新分組、搜尋調校和部分重組可以公平比較。

只有當重要任務在相關情境下反覆出現、有觀察證據支持、屬結構性而且無法合理地局部修復，較廣泛的改版或遷移才有充分理據。修正後要用相同任務、相關起點及所選觀察重新測試，才可判斷問題是否真的改善，而非只把困難移到另一條路線。若任務組合、研究設計或結構取捨超出團隊能力，應邀請有經驗的資訊架構師或用戶研究員參與。

任務式資訊架構審核及本文引用的幾項WCAG檢查，都不能證明整個網站符合無障礙要求。若發現涉及鍵盤操作、輔助科技、語義結構或其他無障礙問題，應交由合資格的無障礙專業人員按適用準則進行完整評估。審核最後交付的應是清楚的重測決定、負責人及證據缺口，而不是在未有足夠證據前先畫好的新網站地圖。