導覽
導覽決定結構的哪些部分在螢幕上獲得永久位置，哪些則以其他方式觸及。位置是稀缺的，每個表面都有其自己的規則來決定什麼能贏得一個位置。
你首先需要什麼
| 輸入 | 來源 | 如果缺失怎麼辦 |
|---|---|---|
| 每個當前的表面 | 在程式碼庫中，首先讀取路由和導覽元件（頁首、頁尾、應用程式切換器、側欄、標籤列）。絕不要僅從首頁重新設計。 | 要求螢幕截圖或每個表面的項目清單。 |
| 背後的樹狀結構 | 網站地圖或路由 | 自行繪製當前的樹狀結構，並說明你這麼做。如果結構本身有誤，停止並使用 sitemaps。 |
| 首要任務、用戶失敗的任務及使用情況 | 用戶、分析工具、搜尋記錄、重複的支援問題 | 詢問，或在最上方陳述你的假設。絕不估計使用量；說明如果有這些數據，哪些決策會改變。 |
如果這些都無法取得，請說明你需要什麼，並使用 references/spec-template.md 產生空的規格書，並填寫進入規則。
方法
-
盤點每個表面。 表面、項目、目的地、數量。標記相同目的地有兩個名稱、指向無處的項目，以及僅偶然存在於一個表面的任何內容。
-
區分全域與本地。
全域 本地 功能 這個整體場所提供的內容 這個頁面周邊的內容 顯示 每個頁面都相同 僅在其所屬章節內 表面 主選單、實用工具、頁尾 側欄、頁面內目錄、麵包屑、相關連結 問題出現時 它列出了某個章節的子項目 它重複了全域項目 一個需要超過兩層導覽的章節，通常需要自己的側欄或自己的首頁。
-
為每個表面賦予進入規則，並將其應用於每個項目。
表面 什麼屬於這裡 什麼不屬於 進入規則 主選單 對用戶和業務最重要的 3 到 6 個目的地 任何尚未贏得該位置的項目 服務於首要任務或明確的業務目標，對新手有意義，且勝過已存在的最弱項目 實用工具 登入、帳戶、搜尋、語言、設定 行銷優先的項目 與用戶的會話或工具相關，而非內容本身 頁尾 更完整的網站地圖、法律條款、聯絡資訊、次要行動呼籲 雜物抽屜（用戶和爬蟲仍然會讀取它） 有人需要從任何頁面存取它，或法律要求如此；它屬於一個已命名的群組 情境相關 側欄、頁面內目錄、麵包屑、相關連結 任何全域性項目 僅在此處有意義，並且根據書面規則放置 應用程式標籤列 最多 5 個標籤；第 6 個變成「更多」或被刪減 少用的目的地 產品中重複出現的頂層任務 -
分配。 如果主選單項目超過七個，視為有些項目沒有贏得自身位置的跡象：合併它們或將它們移至頁尾。將幾乎相同的項目合併為一個。為每個用戶失敗的任務指定一個規範首頁，並說明任何其他入口點都應導向該處。
-
提供兩到三種安排方式（按任務、按物件、按受眾），每種方式說明其代價與可能造成壓力的點。推薦其中一種並說明原因。
-
選擇模式。
情境 使用 注意事項 一個項目有三個以上自有子項目的子群組 巨型選單 將其鍵盤焦點與行動版本設計為獨立工作 子項目清單短而扁平 簡單的下拉選單，或連結到樞紐頁面 通常樞紐頁面更好 深度達三層或以上 麵包屑 每個麵包屑都是一個真實頁面。每個頁面只有一條路徑，遵循規範首頁，而非用戶走過的路徑。 較長的參考頁面 頁面內目錄 僅限本地 不同角色需要不同的起點 個人化捷徑 個人化捷徑，而非地圖。如果每個人看到的選單都不同，人們就無法指路，支援團隊也無法描述東西在哪，分析數據也失去意義。 -
現在就設計行動版與鍵盤操作。 在行動版上，說明主選單如何摺疊、哪些保持可見，以及每個巨型選單如何處理。在鍵盤操作上，每個項目都應能按視覺順序觸及，焦點可見，Enter 打開的內容可用 Escape 關閉，且沒有任何功能僅靠懸停觸發。詳情請見
references/mobile-and-keyboard.md；對於任何會打開的選單，請閱讀該文件。 -
在決策點放置提示。 一個好的提示，能在用戶已經思考、做出選擇、視線所在之處，安靜且低成本地回答他們已有的問題。汽車燃油表旁的箭頭指示油箱蓋在哪一側，就是典範。使用啟用狀態顯示當前位置。
-
規劃項目如何離開。 移除連結不等於移除頁面。
步驟 做什麼 決定其命運 合併、移至頁尾或實用工具、僅透過搜尋可達、或消失 如果頁面消失 將其加入重新導向對應表 如果頁面保留 確認仍有其他路徑可達 告知用戶 在需要登入的產品中，在舊位置留下一個指引，持續一到兩個版本週期，並修正提及舊路徑的說明文章、導覽及電子郵件 保留詞彙 保留舊標籤作為搜尋同義詞，然後觀察搜尋與支援的狀況 -
將驗證交接給
tree-tests。 它會撰寫測試計畫與任務。提供每個促使此工作的問題、你感到不確定的每個放置位置，以及提出的答案。目標：至少 70% 成功率，首要任務 80%，路徑比最多 1.5。
交付成果
navigation-spec.md，依此順序：
- 建議： 兩到三句話並說明主要原因。
- 當前狀態： 每個表面、其數量、其問題。
- 方案： 每種安排一行，附帶其代價。
- 規格： 每個表面、標籤與目的地，以及每個主選單項目為何贏得其位置。接著是麵包屑模式、行動版、鍵盤操作與啟用狀態。
- 規範首頁： 每個問題任務、其一個首頁，以及導向該處的入口點。
- 前後對照： 每個當前項目及其去向，包括已退役項目的處理方式。
- 進入規則： 新頂層項目必須通過的測試。
- 假設與未解決問題。
- 交接給
tree-tests： 問題任務、不確定的放置位置以及提出的答案。
縮小規模。一個選單重新思考需要診斷、新的樹狀結構、每個問題任務一個首頁，以及交接給 tree-tests；它不需要內容模型或 URL 政策。文件越長並不代表越全面。若要求為每個項目安排位置，則每個項目都必須有歸宿。
檢查清單
沒有腳本。這些檢查都很簡短且需要閱讀規格書，因此請手動執行並修正未通過的項目：
- 計算主選單項目（最多 7 個，偏好 3 到 6 個）與標籤（最多 5 個）。
- 每個當前項目都出現在前後對照表中，附有新的位置或明確的退役狀態。
- 每個目的地都存在於樹狀結構或路由中，每個麵包屑的父層級都是一個真實頁面，且側欄、麵包屑與 URL 講述相同的故事。
- 每個問題任務都正好有一個首頁，並出現在
tree-tests的交接清單中，附帶其提出的答案。 - 沒有未經授權的使用量聲明。頻率詞彙需標記為假設。
Claude 在此無法做到的事
- 除非被告知，否則無法了解組織的策略或政治。哪個項目贏得位置部分是業務決定，因此請提供草稿並說明這是誰的決定。
- 無法憑空生成流量、使用量或研究，也無法對真實用戶執行樹狀測試。
- 無法說明某個框架的選單元件能做什麼。請說明你的期望，並請用戶確認，因為平台支援的內容各不相同。
交接至何處
information-architecture：當任務橫跨數個此類範疇時，作為前端入口。sitemaps：當底層的樹狀結構需要改變時。labeling：用於為項目制定用詞。taxonomies：當真正需要的是篩選器或分面時。url-structure與redirect-maps：當目的地網址改變時。content-models：當情境規則需要背後的欄位支援時。tree-tests：用於執行研究。findability：當問題是搜尋或線索時。content-inventory與card-sort：當沒有人知道那裡有什麼或人們如何歸類時。