Findability（可尋性）
「使用者找不到東西」是一種症狀，通常有四種常見原因，每種原因需要不同的解決方案。此技能協助決定優先改變什麼：它將原因與抱怨分離，選取最便宜的修復方案，並設定衡量標準來驗證是否見效。
開始之前
| 你需要 | 如果缺少 |
|---|---|
| 使用者找不到什麼、他們是誰、以及他們在哪裡搜尋 | 詢問。如果答案模糊，列出候選項目並視為假設。 |
| 網站、應用程式或其導覽結構 | 詢問。若無，你只能撰寫診斷計畫。 |
搜尋日誌（CSV 格式）：query,count,results，如有 clicks 更佳 | 告知如何匯出以及涵蓋期間。交付診斷計畫、衡量指標和空白表格。切勿推測日誌內容。 |
| 分析資料、支援問題、內容清單 | 說明哪些結論會因此改變，並標記為未確認。 |
方法
-
將失敗寫成一個任務。 「一位 [誰] 試圖 [目標]，在 [哪裡] 尋找 [事物]，結果 [發生什麼事]。」每項抱怨一行，使用他們自己的話語。
-
讀取日誌並使用其數字。
node "${CLAUDE_SKILL_DIR}/scripts/search-log.mjs" searches.csv如果表示日誌太小無法排名，則將其作為使用者輸入的詞彙清單，不陳述任何比率。說明匯出涵蓋的期間；腳本無法得知。
-
先診斷，再開處方。 依序處理原因，因為每個原因都建立在之前的原因之上。可能同時存在多個原因。將每個結論標記為「已確認」或「推斷」。
原因 如何確認 常見修復 相關技能 不存在（Missing）： 內容根本不存在 檢查所有使用者可能使用的名稱。零結果查詢，且任何地方都沒有匹配的內容 建立內容，或明確說明未提供 content-inventory 標籤不良（Badly labelled）： 內容存在但名稱不同 使用者的詞彙導致零結果或無點擊，但內容存在於你的命名下；出現跳出（pogo-sticking）行為 重新命名，加入同義詞 labeling 深埋（Buried）： 命名良好，但無路徑可達 從首頁和樞紐頁計算步驟數；尋找孤立頁面、死胡同、深層分頁作為唯一路徑，以及使用者在應該提供該內容的頁面上開始搜尋 在使用者已經查看的地方加入連結，或移動內容 navigation, sitemaps 搜尋失敗（Search is failing）： 內容存在，查詢匹配，但結果錯誤 親自執行主要查詢並閱讀結果；結果無點擊、重新措辭、從結果頁面離開 最佳搜尋結果、同義詞、索引範圍、排名 步驟 5 許多可尋性問題透過調整標籤和分組比修改搜尋引擎更便宜，因此不要從引擎開始。深度本身不是問題：三擊規則是一個迷思，當每個步驟都明顯接近目標時，使用者會願意點擊更多次。
-
決定哪條路徑應該有效。 同時支援瀏覽和搜尋，因為使用者會在兩者之間切換。主要查詢應能在一兩步內從首頁抵達。
使用者類型 應強化的路徑 知道確切名稱 搜尋，或 A 到 Z 清單 知道需求但不知道名稱 使用清楚標籤瀏覽，然後使用篩選條件 正在探索或比較 瀏覽、篩選器、相關連結 正在返回某個項目 最近項目、已儲存的檢視、捷徑 正在進行任務中 在他們正在操作的地方提供情境連結或提示 -
若搜尋是原因，則修復搜尋。 為主要查詢的頂端結果設定策展的最佳搜尋結果。從腳本的變體分組中建立同義詞組，從標記為
SYNONYM WOULD ANSWER的開始，再加入只有人能發現的，例如縮寫和行話。永遠不要讓「無結果頁面」成為死胡同。references/search-tuning.md 涵蓋這三者以及匯出事項。 -
在決策發生的地方放置提示。 一個好的提示能夠在使用者做出選擇的時刻、在他們已經查看的地方，安靜且低成本地回答他們已有的問題。汽車油量表旁的箭頭顯示油箱蓋在哪一側就是典範。在加入提示或個人化入口點之前，請先閱讀 references/routes-and-cues.md。
-
如果有人提議以 AI 對話作為解決方案，請先測試它。 按鈕和選單讓人們能夠行動並展示系統能做什麼。開放的對話框在這方面前者緩慢，後者完全無法做到。
情境 更好的答案 有限且可預知的選項組合 按鈕、選單或篩選器 使用者不知道系統能做什麼 可見的結構；空白對話框毫無引導作用 步驟已知的重複性任務 直接路徑 內容不存在或標籤錯誤 先修復那些；對話無法擷取不存在的內容 真正開放式、每次措辭都不同 對話可以發揮作用，但周圍需要有結構 -
設定你能實際收集到的衡量指標。 在改變任何事物之前先取得基線，每個問題一個指標。如果沒有基線，請如實說明。
衡量指標 資料來源 目標 找到簡單項目的時間 與真人進行的計時任務測試 30 秒以內 任務成功率 任務測試或樹狀測試 至少 70%，頂層任務達到 80% 搜尋中零結果的佔比 搜尋日誌 低於自身基線 搜尋跳出、重新措辭 分析工具（如果結果頁面有追蹤） 低於自身基線 此主題的支援量 客服系統（如果有標籤） 低於自身基線 references/measures.md 說明每個指標能與不能顯示什麼。
交付物
除非使用者指定其他檔案名稱，否則撰寫 findability-diagnosis.md，依序包含：建議（兩三句話）；失敗描述（以任務形式呈現）；證據（來源、期間、腳本產生的數字）；診斷（事物、原因、證據、已確認或推斷）；選項（兩三個，說明每個選項的成本和未修復的問題）；依序排列的修復清單（附帶負責的技能）；最佳搜尋結果與同義詞（query、action、target）；無結果頁面（如適用）；衡量指標（名稱、基線、目標、來源、複查日期）；假設與未取得的資料。
| 任務 | 回傳格式 |
|---|---|
| 某個沒人找得到的東西 | 回覆中包含：失敗、原因、證據、修復方案和一個衡量指標 |
| 要讀取的搜尋日誌 | 證據、最佳搜尋結果與同義詞，以及零結果的缺口 |
| 「整個網站的可尋性都很差」 | 完整的文件 |
將長表格放在最後。文件更長不代表更深入。
檢查清單
- 每個數字都能追溯到腳本執行或使用者提供的來源。如果日誌有變，重新執行腳本。
- 每個修復方案都指出其解決的原因，且每個原因都有證據或標記為推斷。
- 如果你有存取權限，請親自執行主要查詢，因為日誌無法判斷結果是否良好。
- 檢查每個提議的同義詞是否同義。腳本根據拼寫分組，因此可能將意義不同的詞彙配對在一起。
- 搜尋日誌可能包含輸入在搜尋框中的姓名和電子郵件。腳本會隱藏電子郵件地址；請勿將其他個人詳細資料複製到報告中。
Claude 在這裡無法做到的事
你無法觀看真實使用者搜尋、為他們計時，或在未被告知的情況下了解組織的策略。永遠不要虛構使用數字、搜尋量、成功率或引述；沒有資料的衡量指標應顯示為「尚未收集」。提出替代方案及其權衡取捨，推薦一個並說明原因；人類擁有最終決定權。搜尋產品的功能（同義詞、置頂結果、查詢記錄）各不相同，因此請說明你的預期並要求使用者確認。
此處轉交的下個階段
| 下一個需求 | 相關技能 |
|---|---|
| 找出存在什麼內容 | content-inventory |
| 名稱錯誤 | labeling |
| 術語和篩選器需要調整 | taxonomies |
| 分組不符合使用者的思維方式 | card-sort |
| 通往內容的路徑遺失 | navigation, sitemaps |
| 測試修改後的階層結構 | tree-tests |
| 篩選面或預覽所需的欄位 | content-models |
| 頁面移動 | url-structure, redirect-maps |
| 整個網站的重新架構，或不確定從何開始 | information-architecture |