information-architecture

name	information-architecture
description	規劃資訊架構、內容層級與導航結構,讓使用者更容易理解與找到資訊。當任務涉及網站地圖、內容分類、導航重組、卡片分類、tree testing 或大型內容結構設計時使用。
license	MIT
metadata	{"author":"goodux","version":"1.0.0","category":"interface-design","language":"zh-TW"}

資訊架構設計法則

任務定義

定義內容分類、命名規則、層級深度與導航路徑,讓使用者能以更低成本找到資訊並完成任務。

何時使用

• 設計新產品或網站的結構時
• 重新組織現有內容時
• 使用者反映難以找到資訊時
• 內容量大且複雜時

必要輸入

• 內容清單或網站頁面清單
• 主要任務流程與使用者需求
• 現有導航與分類問題
• 目標平台與內容規模
• 可用研究方法與驗證方式

預期輸出

• 內容盤點結果
• 分類與層級架構
• 主導航與次導航建議
• 網站地圖或 IA 草圖
• 驗證任務與改善建議

完成條件

• 已完成內容盤點並辨識高頻任務與核心內容群組
• 已建立清楚的分類邏輯、命名原則與層級深度
• 已產出可溝通的網站地圖、模組結構或導航架構
• 已說明此架構如何回應使用者心智模型與任務流程
• 已提出至少一種驗證方式,如卡片分類或 tree testing

不適用情境

• 只需要單頁版面配置,更適合 wireframing
• 問題主要在視覺美感而非找資訊成本
• 內容量很小且結構已明確,不必做完整 IA 流程

常見誤用

• 直接沿用內部組織架構來命名分類,忽略使用者語言
• 把所有內容平均對待,沒有區分高頻與低頻任務
• 層級太深、分類太細,讓使用者需要多次判斷才能找到資訊
• 只畫網站地圖,沒有說明命名邏輯與使用情境
• 沒有驗證架構,就直接進入介面設計或開發

觸發條件

• 使用者提到「資訊架構」、「IA」、「網站地圖」、「導航重組」、「分類」、「卡片分類」
• 任務需要整理大量內容、重做選單或改善找不到資訊的問題
• 任務需要定義網站或產品的整體內容結構

高複雜度觸發

• 任務涉及大型 B2B 平台、內部後台、文件中心或多模組產品
• 使用者提到不同角色看到不同內容、不同權限或不同導航入口
• 問題包含資訊過載、功能太多、選單過深、命名混亂或跨系統切換
• 團隊需要同時兼顧新手與專家使用者,或同時服務管理者與第一線操作人員

必要澄清

• 這個產品包含哪些主要模組、內容類型或任務區塊?
• 有哪些角色會使用這個資訊架構?他們看到的內容是否相同?
• 使用者最常執行的高頻任務是什麼?最常找不到的是哪些資訊?
• 現有導航有幾層?是否存在重複命名、內部術語或分類衝突?
• 是否需要依權限、組織層級或流程階段顯示不同資訊?
• 這次 IA 調整的成功標準是什麼?例如搜尋時間更短、任務成功率更高或培訓成本更低

可搭配技能

• user-interview: 先理解不同角色如何命名與尋找資訊
• wireframing: 將 IA 結果轉成具體的頁面與導航骨架
• usability-testing: 用 tree testing 或原型驗證新架構是否可用
• persona-creation: 區分不同角色的心智模型與資訊需求

執行步驟

1. 盤點內容: 列出頁面、功能、內容類型與高頻任務。
2. 建立分類: 用使用者語言分組,避免直接照組織架構命名。
3. 定義層級: 控制深度與選單數量,讓高頻任務更容易抵達。
4. 產出架構: 整理主導航、次導航、網站地圖或模組關係。
5. 驗證架構: 用卡片分類、tree testing 或原型測試確認命名與路徑是否合理。

執行檢查

• 已完成內容盤點與高頻任務整理
• 已建立清楚分類與命名規則
• 已控制層級深度與導航負荷
• 已產出網站地圖或模組架構
• 已規劃至少一種驗證方法

精簡範例輸出

# 後台資訊架構

主導航:
- 儀表板
- 客戶
- 報表
- 權限
- 設定

命名原則:
- 優先使用使用者語言
- 相同概念只保留一種叫法

待驗證:
- 新使用者能否找到權限設定
- 報表與通知是否應分開

範例資料庫

本技能提供完整的資訊架構範例庫，請參考 examples.yaml：

• 架構模式：階層式、資料庫式、線性式、矩陣式等常見架構模式
• 導航類型：全域、區域、情境、工具導航的設計指南
• 卡片分類指南：開放式與封閉式卡片分類方法
• 網站地圖範例：電商、SaaS 等實際架構範例
• 標籤原則：清晰易懂的標籤命名最佳實踐

使用方式：根據產品類型選擇適合的架構模式，參考範例快速建立資訊架構。

資料使用規則

• 產出內容前，先閱讀 TEMPLATE.md，確認欄位結構、最小必要欄位、品質標準與驗證方式。
• 接著再閱讀 examples.yaml，從既有架構模式、導航類型、網站地圖與命名原則中選取最適合的內容。
• 若要新增資料，優先沿用 TEMPLATE.md 的格式與命名規則，避免建立重複或邊界模糊的分類。
• 最終輸出必須優先對齊 TEMPLATE.md 的格式要求，其次再引用 examples.yaml 的內容細節。