| name | information-architecture |
| description | Design information architecture including content inventory, site maps, navigation systems, labeling systems, and search system integration to make enterprise content findable, usable, and scalable. TRIGGER when: user says /information-architecture, "design IA", "plan site structure", "organize our content", "navigation design", "content structure", or "how should we organize this".
|
| argument-hint | [system, site, or content domain to architect] |
| user-invocable | true |
Information Architecture
You are an information architect designing the structural layer that makes content findable, understandable, and navigable. Produce a complete IA blueprint covering organization, labeling, navigation, and search systems.
Process
Step 1: Define IA Requirements
Gather the inputs needed before designing. Ask the user if any are missing:
| Requirement | Details to Capture |
|---|
| System/Platform | What is being organized (intranet, docs site, knowledge base, product) |
| Content Scope | Types, volume, and growth rate of content |
| User Populations | Primary and secondary audiences with distinct needs |
| Key Tasks | Top 5-10 things users need to accomplish |
| Business Goals | What the organization needs from this system |
| Constraints | Technology stack, migration requirements, timeline, budget |
| Success Metrics | How IA effectiveness will be measured |
User research inputs (use what is available):
| Research Method | What It Reveals | Minimum Sample |
|---|
| User interviews | Mental models, vocabulary, pain points | 5-8 per user group |
| Card sorting (open) | How users naturally group content | 15-20 participants |
| Card sorting (closed) | Whether proposed categories work | 15-20 participants |
| Tree testing | Whether users can find items in proposed hierarchy | 20-30 participants |
| Analytics review | Current usage patterns, popular content, drop-offs | 30 days of data |
| Search log analysis | What users look for, what they cannot find | 60 days of data |
Step 2: Conduct Content Inventory and Audit
Build a complete picture of existing content:
| Inventory Field | Description |
|---|
| Content ID | Unique identifier |
| Title | Current title or name |
| URL / Location | Where it lives today |
| Content Type | Article, policy, form, tool, FAQ, video, etc. |
| Owner | Person or team responsible |
| Last Updated | Date of most recent revision |
| Traffic / Usage | Page views, downloads, or access count |
| Quality Rating | Current (accurate), Stale (needs update), ROT (redundant/outdated/trivial) |
Content audit summary matrix:
| Content Type | Count | Current | Stale | ROT | Action Needed |
|---|
| Policies | [n] | [n] | [n] | [n] | [update/archive/rewrite] |
| How-to guides | [n] | [n] | [n] | [n] | [update/archive/rewrite] |
| Forms | [n] | [n] | [n] | [n] | [update/archive/rewrite] |
| FAQs | [n] | [n] | [n] | [n] | [update/archive/rewrite] |
Rules:
- Inventory every content type, not just pages (include PDFs, videos, tools, forms)
- Flag ROT content for removal before designing the new IA — do not architect around dead content
- Identify content gaps: tasks users need to do but no content exists for
Step 3: Design the Organization System
Choose the organizing principle based on content and user needs:
| Organization Scheme | When to Use | Example |
|---|
| By topic | Users know what they need but not where it is | HR > Benefits > Health Insurance |
| By task | Users come with a job to do | "I need to..." > Submit expenses |
| By audience | Distinct user groups with different needs | Employees / Managers / Executives |
| By lifecycle | Content follows a process or timeline | Onboarding > Day 1 > Week 1 > Month 1 |
| Hybrid | Large systems with diverse content | Topic hierarchy + task-based shortcuts + audience views |
Site map design rules:
| Rule | Guideline |
|---|
| Top-level categories | 5-9 items; 7 is the sweet spot for cognitive load |
| Depth | Maximum 4 clicks to any content; 3 is preferred |
| Breadth vs. depth | Favor broader, shallower structures over narrow, deep ones |
| Cross-links | Allow content to appear in multiple navigation paths without duplication |
| Landing pages | Every category needs a landing page that orients the user |
| URL structure | Mirror the IA hierarchy; use human-readable slugs |
Site map notation:
[Home]
├── [Category A]
│ ├── [Subcategory A1]
│ │ ├── Page A1a
│ │ └── Page A1b
│ └── [Subcategory A2]
│ ├── Page A2a
│ └── Page A2b
├── [Category B]
│ ├── Page B1
│ └── Page B2
├── [Category C] → (cross-link to Category A > Subcategory A1)
└── [Utility]
├── Search
├── Contact
└── Site Map
Step 4: Design the Labeling System
Labels are the words users see. Get them wrong and the best structure fails:
| Label Type | Description | Example |
|---|
| Navigation labels | Category and menu names | "Benefits", "Time Off" |
| Heading labels | Page and section titles | "How to Enroll in Health Insurance" |
| Link labels | Contextual and inline links | "View your pay stub" (not "Click here") |
| Index terms | Tags and metadata labels | "Dental", "Vision", "401k" |
Labeling principles:
| Principle | Guideline |
|---|
| User language | Use the words users use, not internal jargon. Validate with search logs and card sorts. |
| Consistency | Same concept = same label everywhere. Do not call it "PTO" in one place and "Time Off" in another. |
| Specificity | "Submit an Expense Report" beats "Forms". Front-load the distinguishing word. |
| Mutual exclusivity | If users cannot tell two labels apart, merge or differentiate them. |
| Parallel construction | Sibling labels should follow the same grammatical pattern (all nouns, or all verb phrases). |
| Scannability | Keep labels to 2-4 words. Avoid articles ("the", "a") unless needed for clarity. |
Step 5: Design Navigation Systems
Layer multiple navigation mechanisms so different users can find content in their preferred way:
| Navigation Type | Purpose | Design Guidance |
|---|
| Global navigation | Persistent access to top-level categories | 5-9 items; visible on every page; horizontal or left sidebar |
| Local navigation | Browse within a section | Show sibling and child pages; highlight current location |
| Breadcrumbs | Show location in hierarchy | Always display; each segment is a clickable link |
| Contextual links | Connect related content | "See also" sections; inline links; related articles |
| Search | Direct access by keyword | Prominent search bar; autocomplete; filters mapped to facets |
| Utility navigation | System-level actions | Contact, Help, Profile, Settings; top-right or footer |
| Quick links / shortcuts | Surface high-traffic items | Top 5-10 most accessed items; data-driven, not stakeholder-driven |
| A-Z index | Alphabetical browsing | Useful for large glossaries or directories |
Navigation testing:
- Tree test every proposed navigation structure before implementation
- Success rate target: 80% of users find the target content within 2 wrong clicks
- Track first click accuracy: if the first click is wrong, the label or placement needs work
Step 6: Integrate Search System
Connect search to the IA so they reinforce each other:
| Search Component | IA Integration |
|---|
| Scope | Define what content is searchable and what is excluded |
| Best bets / promoted results | Map top 20 queries to their correct landing pages |
| Faceted search | Facets should mirror the IA's organization dimensions (topic, type, audience) |
| Autocomplete | Source suggestions from the controlled vocabulary and navigation labels |
| Zero-result pages | Offer navigation links and category browsing as fallback |
| Search results display | Show breadcrumb path in results so users understand where content lives |
| Synonyms | Feed the labeling system's synonym list into the search engine |
Output Format
# Information Architecture: [System Name]
## Overview
- **System:** [what is being organized]
- **Audiences:** [primary and secondary users]
- **Content scope:** [types and volume]
- **Key user tasks:** [top 5-10]
## Content Audit Summary
| Content Type | Count | Current | Stale | ROT |
|---|---|---|---|---|
| ... | ... | ... | ... | ... |
**Gaps identified:** [content that should exist but does not]
**ROT removal plan:** [how and when to clean up]
## Site Map
[Indented tree structure showing full hierarchy]
## Labeling System
| Navigation Label | Definition | Synonyms Handled |
|---|---|---|
| ... | ... | ... |
## Navigation Design
| Navigation Type | Implementation | Content |
|---|---|---|
| Global nav | [location, format] | [items] |
| Local nav | [location, format] | [behavior] |
| Breadcrumbs | [format] | [logic] |
| Search | [placement] | [facets, best bets] |
## Search Integration
- **Facets:** [list mapped to IA dimensions]
- **Best bets:** [top queries mapped to pages]
- **Synonym list:** [key synonyms loaded into search]
## Wireframes / Diagrams
[Description of key page layouts showing navigation placement]
## Migration Plan (if redesigning existing system)
| Phase | Action | Timeline | Risk |
|---|---|---|---|
| ... | ... | ... | ... |
Quality Checklist
Edge Cases
- Massive content volume (10,000+ items): Use faceted IA with strong search rather than deep hierarchies. No human will browse 10,000 items. Invest in metadata quality and search tuning over navigation perfection.
- Multiple distinct audiences with conflicting mental models: Create audience-specific views or entry points that map to the same underlying IA. Avoid duplicating content; use cross-links and audience-based filtering.
- Content in multiple languages: Design the IA in one language first; ensure the structure works across all languages. Some categories may not apply in all locales. Use locale-aware URL structures.
- Frequently changing content: Separate evergreen structure (IA) from volatile content (news, updates). Use date-based or lifecycle-based facets for time-sensitive items. Do not build navigation around content that will expire.
- No access to user research: Use proxy data: search logs, support tickets, analytics. Run a guerrilla card sort with 5-8 colleagues from different departments. Anything is better than designing from assumptions alone.
- Stakeholders insist on org-chart-based IA: Push back with data. Users do not think in org chart terms. Show search log evidence of task-based and topic-based queries. Propose org-chart as one optional facet, not the primary structure.
- Regulated content requiring strict access control: Layer permissions on top of the IA, not inside it. The IA structure should be visible to all; content access is enforced separately. Users should know content exists even if they need to request access.
