資訊架構
資訊架構是系統如何將內容和功能分組、標記和連結，使人們能夠找到所需內容並了解他們能做什麼。每個決策都服務於一個測試：這個結構能否幫助面對它的人快速做出正確選擇，無需他人指導？
它位於所有其他事項的上游。錯誤的結構會讓內容無家可歸、設計需要發明額外導航、搜尋導致 URL 頻繁變更，而 CMS 則會變成一堆權宜之計。
這項技能用於界定工作範圍，並涵蓋適用於整個工作的規則。實際工作則存在於以下的技能中。
1. 選擇工作
大多數需求只需要工具組的一部分，而非全部。命名你將產出的內容，讓對方知道他們會得到什麼。
| 工作 | 依序執行這些 |
|---|---|
| 重新組織現有內容 | content-inventory, card-sort 或 taxonomies, sitemaps, url-structure (若地址變更), tree-tests, redirect-maps |
| 新網站、應用程式區域或章節 | sitemaps, navigation, url-structure, content-models |
| 重新思考選單、導航或應用程式切換器 | navigation, labeling, tree-tests |
| 標籤與分類 | taxonomies |
| 不好用的名稱 | labeling |
| 「人們找不到 X」 | findability，然後根據診斷結果指向對應技能 |
| 搬遷或重建網站 | sitemaps, navigation, url-structure, content-models, redirect-maps |
| 在建立前檢查結構 | tree-tests |
| AI 功能或產品 | 此處的第 5 節，然後 findability |
單獨的網站地圖只是裝飾。對於網站建置，完整組合應包含網站地圖、URL 規則、導航規格、內容模型，以及（對於任何重建）重新導向地圖。缺少其他四項，任何人都無法據以建置。
如果同級技能不可用，請在此處使用以下規則完成該部分，並說明原因。
2. 建立框架，然後繪製現狀
在任何路線之前，先確定誰在使用這個系統以及他們想做什麼、目前和兩年後的內容量、業務期望從中獲得什麼，以及如何衡量成功。在進行任何更改之前，記錄這些指標的當前數據，否則之後將無從比較。
然後建立當前的全貌。永遠不要只從首頁開始重新設計。
- 在程式碼庫中： 讀取路由、導航元件、
sitemap.xml、CMS 架構以及任何分類或標籤表格。統計每個區段的項目數。空區段和過載區段本身就是發現。 - 在內容資料夾中： 調查整個語料庫，而不是逐一檢查。說出它是什麼以及它似乎服務於誰，並讓對方在你基於錯誤理解進行建置之前進行糾正。
- 資料庫或 CMS 中的內容： 先匯出標題、類型、標籤和日期。
- 非常大型的集合： 按類型進行調查，並在每種類型內抽樣，同時說明你抽樣的內容，以免有人將抽樣誤認為普查。
此外，也要詢問只有人才知道的資訊：受眾及其首要任務、組織的發展方向、分析資料、站內搜尋日誌，以及客服持續回答的問題。
3. 貫穿工作的規則
- 根據人們想做的事來組織結構，絕不根據組織圖。「給開發者的 API」勝過「關於我們、工程部門、API」。
- 每個項目只有一個正規位置。 它可以從其他地方連結，但它只存在於一個地方。
- 保持氣味線索，而不是點擊次數。 當每一步都清楚地散發出目標的氣味時，人們會繼續點擊。三擊規則是迷思。死胡同和模糊的標籤才是真正的成本。
- 為十倍內容量設計。 如果某個類別會成長，現在就為此設計。
- 提供多種進入方式。 瀏覽、搜尋、篩選器、相關連結、麵包屑導航。
- 在決策發生的地方放置提示。 一個好的提示能在人們做出選擇的時刻、在他們已經關注的位置，安靜且低成本地回答他們已有的問題。
- 為更大的上下文設計。 頁面位於區段中，區段位於網站中，網站位於企業中。
4. 作為 AI 進行 IA 工作
你擅長的事： 在幾分鐘內讀取整個語料庫、提出替代方案、將分類法一致地應用於數千個項目、找出近似重複的術語，以及發現無處可放的項目。
你無法做到的事： 與真實使用者進行卡片分類或樹狀測試，或在未被告知的情況下了解組織的策略和政治。因此：
- 提出建議，而非做出決定。 提供兩三種方案及其權衡取捨，推薦其中一個並說明原因。單一答案會隱藏決策過程。
- 先了解受眾和方向。 如果未告知你是為誰設計以及產品方向，請提問，或在開頭陳述你的假設。
- 放置所有要求你放置的內容。 不合適的項目應放到最不差的位置並加上標記，而關於搬遷、合併或淘汰的理由則作為單獨建議提出。
- 交付所要求的所有成品。 如果你認為某個成品不該存在，仍應交付，並單獨說明理由。
- 絕不編造研究數據。 沒有虛構的參與者人數、成功率、工單數量、引述或頻率。將「每小時使用一次」陳述為事實也算。請說「可能」並將其列為假設。
- 不要猜測平台行為。 主機或 CMS 的功能各異。請說明你的預期，並告知對方確認。
- 保護內容。 在就地編輯內容、中繼資料、路由或重新導向之前，確保工作已納入版本控制或已備份。
5. AI 產品與代理人上下文的 IA
在產品中加入 AI 之前，先找出實際阻礙的因素。如果人們無法理解系統運作方式、無法區分其類別，或一直詢問相同問題，那麼更清晰的結構、更好的標籤或放置得當的提示通常比對話框更便宜地解決問題。按鈕和選單有兩個作用：讓使用者採取行動，並向他們展示系統能做什麼。開放式對話框在第一點上緩慢，在第二點上則完全無效。在任務確實需要開放式探索時使用對話框，其他情況下則在結構化介面背後使用 AI。
為代理人提供上下文也是一個 IA 問題。在正確的時間提供模型正確的資訊：一個指向更深層檔案的簡短入口檔案、每個事實只有一個正規位置、一致的名稱，以及不加載任務不需要的任何內容。
6. 當工作跨越多項技能時
除非要求其他內容，否則應交回一份文件，包含：
- 摘要： 以兩三句話說明建議及其主要原因。
- 現狀： 當前的樹狀結構及其問題，並附上數量。
- 選項： 兩三種方案，每種方案說明其服務對象、成本以及可能產生的壓力點。
- 提案： 建議的樹狀結構，每個節點的範本類型，然後是標籤和導航規格，以及相關的 URL 規則和內容模型。
- 遷移： 新舊對應關係以及重新標記的備註（如果有任何項目移動）。
- 假設與未解決問題： 你所猜測的所有事項。
- 驗證方法： 樹狀測試任務及其正確答案和目標，或者先進行的卡片分類。
根據工作規模調整內容。 以建議開頭，每個章節在保持可用性的前提下盡可能簡短，並將長表格移至結尾。較長的文件並不代表更詳盡。
在交付前自行檢查一致性。 重新統計總數與放置表格是否一致，根據你編寫的表格檢查你陳述的每一條規則，追溯任何關於路徑長度的陳述到樹狀結構，並確保任何可交付檔案實作了其來源計畫的每一行。
若要審查資訊架構（無論是自己的還是他人的），請使用 references/rubric.md 進行評分。
7. 需要指出的模式
- 組織圖導航： 以部門名稱命名的區段。
- 兩個相互競爭的分類法： 側邊欄、麵包屑導航和 URL 各有不同的說法。
- 所有內容放在一個傘下： 每個區段都是
/services/<thing>，像個帶有 URL 的雜物抽屜。 - 佔位區段： 上線的「即將推出」頁面。要嘛建立它，要嘛刪除它。
- 用對話框取代結構： 在清晰的選項能更快回答問題並教會使用者系統運作方式的地方，卻使用開放式 AI 介面。