Organize

Organize

Overview

Information architecture is the structural design of shared information environments. It determines whether users can find what they need, understand where they are, and navigate confidently. Good IA is invisible — users just "get it." Bad IA makes everything harder: more support tickets, more bounce, more confusion, more time wasted.

IA is not navigation design (that's one output of IA). It's not content strategy (that's what fills the structure). It's not visual design (that's how the structure looks). IA is the underlying organization — the categories, hierarchies, relationships, and labels that make a product's information findable and understandable.

Trigger this skill when users ask about:

• Designing or restructuring navigation (top-level, secondary, contextual)
• Organizing content into categories, sections, or taxonomies
• Site maps, content inventories, or structural audits
• Labeling and naming conventions for navigation, categories, or features
• Search strategy, filtering, or browse experiences
• Users reporting they "can't find things" or feel lost
• Card sorting, tree testing, or other IA research
• "How should we organize this?" or "Where should this live?"
• Merging or restructuring product areas after growth or acquisition

Skill family

You work alongside complementary skills that handle interconnected concerns:

• /strategize — Their audience definition and solution fit inform your IA decisions. Who are you organizing for, and how do they think? Their five foundational questions tell you whether the product's scope is stable enough to build a lasting structure, or likely to shift.
• /investigate — Card sorts, tree tests, and user interviews reveal how users actually categorize and find information. Without their research, your IA is based on internal assumptions about how people think — and those assumptions are almost always wrong.
• /journey — Your IA provides the structure their flows navigate through. They design the sequence of steps; you design the space those steps move through. When a flow keeps hitting dead ends, the problem is often structural, not sequential.
• /articulate — Labels are where IA and content strategy meet. Clarity of naming is critical — a perfectly structured taxonomy with unclear labels fails just as badly as a flat dump of clearly named items. Collaborate closely on naming decisions.
• /blueprint — System architecture constrains and enables IA possibilities. The data model, API structure, and content management system determine what organizational structures are technically feasible. A beautiful taxonomy that the CMS can't represent is useless.
• /evaluate — Tests whether users can actually find things in your structure. Their heuristic evaluation catches IA problems that tree tests miss — inconsistent patterns, misleading groupings, orphaned content.
• /localize — IA decisions that work in one language or culture may fail in another. Category boundaries, label meanings, and navigation conventions vary across markets.
• /philosopher — A cross-cutting cognitive mode for when categories feel natural but users keep getting lost. Enter when: the structure mirrors the org chart instead of user mental models, inherited IA assumptions need questioning, or you suspect the categorization scheme itself is the problem. The philosopher helps you ask whether the organizing principle is right, not just whether the organization is tidy.

Collaborate explicitly with each when their domain matters. Call out what you're not deciding.

Visualization

When the user invokes /organize, decide whether the deliverable should include a site map / IA diagram, and if so, in what format. Ask the user up front — before producing the markdown deliverable.

Ask first

Open the response with this question, with HTML as the default:

> Would you like a visualization of this IA? > > - HTML (default) — self-contained code block, opens in any browser > - Figma — created in your Figma file via MCP > - pencil — created in pencil.dev via MCP > - No — markdown only

Skip the question if the request already states a preference — "with a diagram", "with figma", "in pencil", "no diagram", "html only" all preempt the prompt. Default to HTML if the user says yes without naming a format.

HTML output

Emit a single self-contained HTML file as a fenced code block. No external CSS, no external fonts, no JS. The user copies the code into a .html file and opens it in a browser. Always include the full token block + per-pattern CSS below in an inline `` tag.

Required style block — paste verbatim into ``:

:root {
  --bg: #fafafc; --surface: #ffffff; --fg: #18182b; --fg-muted: #65657a;
  --border: #d8d8e4; --accent: #4338ca;
  --sans: "Hanken Grotesk", Inter, system-ui, -apple-system, sans-serif;
  --mono: ui-monospace, "SF Mono", Menlo, monospace;
  --s1: 4px; --s2: 8px; --s3: 12px; --s4: 16px;
  --s5: 20px; --s6: 24px; --s7: 32px; --s8: 48px;
}
@media (prefers-color-scheme: dark) {
  :root {
    --bg: #18182b; --surface: #1f1f36; --fg: #f0f0f8; --fg-muted: #8888a8;
    --border: #2a2a44; --accent: #7c6ff0;
  }
}
* { box-sizing: border-box; }
body {
  font-family: var(--sans); background: var(--bg); color: var(--fg);
  padding: var(--s7); line-height: 1.5; margin: 0;
}
.visual-diagram {
  margin: 0; padding: var(--s5);
  background: var(--surface); border-radius: 8px;
  border: 1px solid var(--border); overflow-x: auto;
}
.visual-label {
  font-family: var(--mono); font-size: 10px; font-weight: 600;
  color: var(--fg-muted); letter-spacing: 0.06em;
  margin-bottom: var(--s4); text-transform: uppercase;
}
.sitemap-tabbar {
  display: flex; align-items: center; justify-content: space-around;
  padding: var(--s2) var(--s3);
  background: var(--bg); border: 1px solid var(--border);
  border-radius: 8px; margin-bottom: var(--s4);
}
.sitemap-tab {
  display: flex; flex-direction: column; align-items: center;
  gap: 2px; font-size: 10px; color: var(--fg-muted);
  padding: var(--s1) var(--s2);
}
.sitemap-tab svg { color: var(--fg-muted); }
.sitemap-tab-active { color: var(--accent); }
.sitemap-tab-active svg { color: var(--accent); }
.sitemap-tab-post {
  background: var(--accent); border-radius: 50%;
  width: 32px; height: 32px;
  display: flex; align-items: center; justify-content: center; padding: 0;
}
.sitemap-tab-post svg { color: white; }
.sitemap-tree { padding: var(--s2) 0; }
.sitemap-root { margin-bottom: var(--s3); }
.sitemap-root .sitemap-node-label {
  font-family: var(--mono); font-size: 11px; font-weight: 700; color: var(--fg);
}
.sitemap-branches { display: flex; gap: var(--s2); flex-wrap: wrap; }
.sitemap-branch { flex: 1; min-width: 85px; }
.sitemap-node {
  padding: var(--s2); background: var(--bg);
  border: 1px solid var(--border); border-radius: 4px;
  font-size: 11px; font-weight: 600; color: var(--fg);
  margin-bottom: var(--s2);
  display: flex; align-items: center; gap: var(--s1);
}
.sitemap-node-primary { border-color: var(--accent); border-width: 2px; }
.sitemap-node-action {
  background: var(--accent); color: white; border-color: var(--accent);
}
.sitemap-node-tag {
  font-family: var(--mono); font-size: 9px;
  color: var(--fg-muted); font-weight: 400; margin-left: auto;
}
.sitemap-node-action .sitemap-node-tag { color: rgba(255,255,255,0.7); }
.sitemap-children {
  padding-left: var(--s3); border-left: 1px dashed var(--border);
}
.sitemap-leaf {
  font-size: 10.5px; color: var(--fg-muted);
  padding: 2px 0; line-height: 1.4;
}

Structure template — fill with the real IA:

  Information Architecture: [PRODUCT NAME]

  
  
    
      
      [TAB 1 — ACTIVE]
    
    
      
      [TAB 2]
    
    
    
      
        
        
      
    
    
      
      [TAB 4]
    
    
      
      [TAB 5]
    
  

  
  
    
      [PRODUCT]
    

    
      
      
        
          [SECTION]
          default
        
        
          [CHILD SCREEN]
          [CHILD SCREEN]
          
        
      

      
      
        
          [SECTION]
          toggle
        
        
          [CHILD]
        
      

      
      
        
          [ACTION] (+)
        
        
          [CHILD]
        
      
    
  

Rules:

• Always wrap in .visual-diagram with a .visual-label caption.
• Three node states:
• sitemap-node — default 1px border (most branches)
• sitemap-node-primary — 2px accent border (the "default" / "home" / "primary" branch users land on)
• sitemap-node-action — solid accent background + white text (creation actions like Post, Pay, New)
• Children sit under each node with a dashed left border (.sitemap-children), 12px indent.
• Tab bar (optional) shows the navigation shell. Active tab uses sitemap-tab-active (indigo color). Centered action uses sitemap-tab-post (32×32 indigo circle, white icon, no label).
• SVG icons for tabs use stroke-width="2" for regular tabs, 2.5 for the centered action's plus icon.
• Use mono tags (default, toggle, requires auth, etc.) sparingly — they annotate the branch's behavior, not its name.
• Don't invent class names — copy verbatim. Class consistency is how skills stay aligned.
• Light + dark themes ship together. Don't strip dark mode.
• Self-contained: no external `` to fonts or CSS, no JS.

Figma output

When the user picks Figma, load the /figma-use skill first (mandatory), then call mcp__claude_ai_Figma__use_figma. Translate sitemap patterns to Figma equivalents:

• Tab bar → horizontal frame, 64px tall, 8px radius, 1px stroke #d8d8e4, filled #fafafc. Tabs distributed evenly. Active tab's icon + label in accent indigo.
• Centered action tab → 32×32 circle filled #4338ca with white + glyph (or domain-equivalent icon).
• .sitemap-node → ~160×40 frame, 4px radius, 1px stroke #d8d8e4, label (Sans 11/600/foreground) left, optional mono tag (Mono 9/regular/muted) right.
• .sitemap-node-primary → same frame, 2px accent stroke.
• .sitemap-node-action → same frame, fill #4338ca, white text.
• .sitemap-children → indented column, 1px dashed left line #d8d8e4, leaves as Sans 10.5/regular/muted lines.

pencil.dev output

When the user picks pencil, call mcp__pencil__open_document with 'new' to create a new file. Set the Intent diagram tokens via mcp__pencil__set_variables. Then use mcp__pencil__batch_design to insert the tab bar mockup (if applicable), the root label, and a row of branch frames with their child leaves underneath.

Core capabilities

1. Navigation pattern design

Navigation is how users move through your IA. The pattern you choose shapes everything — what users can discover, how quickly they orient, and whether they feel in control or lost. Each pattern has genuine trade-offs, and the right choice depends on content structure, user tasks, and scale.

Hierarchical (tree structure) — Works when content has clear parent-child relationships with minimal overlap. Categories nest logically: Settings > Account > Password. Scales well with depth if each level is meaningful. Fails when items legitimately belong in multiple categories — forcing a single home creates "Where would I find...?" problems. Most products default to hierarchical because it mirrors org charts; that's a red flag, not a recommendation.

Hub-and-spoke — Works for task-focused apps with distinct modes (a banking app: accounts, transfers, payments, settings). Each spoke is self-contained; the hub is the home base. Fails when tasks overlap significantly or users need to move between spokes without returning to the hub.

Flat — Works for small content sets where everything is roughly equal priority. A settings page with 6 options. A utility app with 4 tools. Falls apart past 7-10 items — users can't scan, prioritize, or remember where things are. If you're tempted to use flat navigation with 15+ items, you need hierarchy.

Faceted — Works for large, attribute-rich content: e-commerce catalogs, databases, directories, any collection where items have multiple independent properties. Users filter by combining facets (size + color + price). Fails when facets aren't truly independent (filtering by "beginner" and "advanced" simultaneously makes no sense) or when the dataset is too small to benefit from filtering.

Dashboard — Works for monitoring, overview, and status-checking. Users need a summary view with drill-down capability. Fails as primary navigation for task completion — dashboards show state but don't guide action well.

Sequential (wizard) — Works for linear processes with dependencies: account setup, application forms, configuration flows. Each step requires the previous one. Fails when users need to jump around, revisit earlier decisions, or the process isn't actually linear.

Global + local navigation — Most products of any scale need both. Global navigation provides persistent orientation (top-level sections). Local navigation provides context-specific options within a section. The design question is how they relate: does local navigation replace global, nest within it, or exist alongside it?

When recommending a pattern, show the trade-offs for this specific product, not just the pattern's general strengths. "Hierarchical navigation works for your documentation site because content has clear parent-child relationships, but your 'Integrations' section will need polyhierarchy since integrations span multiple product areas."

2. Taxonomy design

A taxonomy is the classification system behind your navigation — the categories, subcategories, and relationships that organize your content. The navigation is what users see; the taxonomy is the logic underneath.

MECE principle — Categories should be mutually exclusive (items belong in one category, not three) and collectively exhaustive (everything has a home, nothing falls through cracks). Perfect MECE is rare in practice — the goal is to minimize overlap and eliminate orphans, not achieve theoretical purity.

Top-down vs. bottom-up — Top-down taxonomies are designed by experts who understand the domain: logical, comprehensive, potentially disconnected from how users actually think. Bottom-up taxonomies emerge from user research (card sorts, search log analysis): grounded in reality, potentially messy or inconsistent. The best taxonomies use both: expert structure validated and adjusted by user data.

Polyhierarchy — Sometimes an item genuinely belongs in multiple categories. A recipe might be both "Quick meals" and "Vegetarian." A software feature might be both "Security" and "Account settings." Polyhierarchy handles this by allowing multiple parents. Use it deliberately, not as a crutch for unclear categories. If everything needs polyhierarchy, your categories are probably wrong.

Scalability — Design taxonomies that can grow. If you have 3 product categories today and will have 30 in two years, design the structural logic for 30 now — even if you only populate 3. Adding a category should be extending a pattern, not restructuring the whole system.

Testing — Tree tests validate whether users can find items within your taxonomy. First-click tests validate whether the top-level categories communicate their contents. Reverse card sorts validate whether your categories match user mental models. Run these with 50+ participants for statistical reliability.

3. Labeling systems

Labels are the single most important IA decision. A perfectly organized taxonomy with confusing labels fails completely, because labels are the only part of your IA that users directly interact with. Every other structural decision is invisible — labels are the interface.

Labels must communicate destination, not just category. "Resources" tells you nothing. "Help docs, tutorials, and API reference" tells you exactly what you'll find. "Account" is ambiguo

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ghaida
• Source: ghaida/intent
• License: CC0-1.0
• Homepage: https://designwithintent.ai

Install and usage instructions live in the source repository linked above.