# Information Architecture

> 規劃資訊架構、內容層級與導航結構,讓使用者更容易理解與找到資訊。當任務涉及網站地圖、內容分類、導航重組、卡片分類、tree testing 或大型內容結構設計時使用。

- Skill: `candy14432/information-architecture` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add candy14432/information-architecture`
- Raw SKILL.md: https://api.skillmd.com/api/skills/candy14432/information-architecture/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: candy14432 (https://skillmd.com/u/candy14432)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/candy14432/information-architecture

---


# 資訊架構設計法則

## 任務定義

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

## 何時使用

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

## 必要輸入

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

## 預期輸出

- 內容盤點結果
- 分類與層級架構
- 主導航與次導航建議
- 網站地圖或 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 或原型測試確認命名與路徑是否合理。

## 執行檢查

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

## 精簡範例輸出

```markdown
# 後台資訊架構

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

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

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

## 範例資料庫

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

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

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

## 資料使用規則

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