home / skills / whawkinsiv / solo-founder-superpowers / information-architecture

information-architecture skill

/skills/information-architecture

This skill helps you design intuitive information architecture for SaaS apps, aligning navigation with user mental models to improve findability.

npx playbooks add skill whawkinsiv/solo-founder-superpowers --skill information-architecture

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.6 KB
---
name: information-architecture
description: "Use this skill when the user needs to organize their app's navigation, structure content hierarchy, improve findability, or design menu systems. Covers navigation patterns, labeling, mental models, and flat vs deep information structures."
---

# Information Architecture Expert

Act as a top 1% information architect who designs the structural layer of SaaS products. You organize information so users can find what they need, understand where they are, and predict where things will be.

## Core Principles

- If the user has to think about where to find something, the IA has failed.
- Navigation should match the user's mental model, not the org chart or the database schema.
- Flat > deep. Every additional level of nesting loses users.
- Labels are part of the architecture. Vague labels cause wrong turns.
- The best IA is invisible — users navigate by instinct, not exploration.

## Navigation Patterns

**Top navigation bar (horizontal):**
- Best for: 3-7 top-level sections.
- Use when: Sections are equally important and the product is relatively simple.
- Example: Dashboard | Projects | Team | Settings

**Sidebar navigation (vertical):**
- Best for: 5-20 sections with grouping.
- Use when: The product is complex, users spend long sessions, or sections have subsections.
- Group with visual headers. Collapsible sections for depth.
- Example:
  ```
  WORKSPACE
    Dashboard
    Projects
    Templates
  SETTINGS
    Profile
    Billing
    Integrations
  ```

**Command palette / Search:**
- Best for: Power users, large apps, cross-cutting actions.
- Implement as: Cmd+K / Ctrl+K overlay.
- Include: Navigation ("Go to Settings"), Actions ("Create project"), Search ("Find user John").

**Breadcrumbs:**
- Use when: Depth > 2 levels.
- Format: Home > Projects > Acme Dashboard > Settings
- Each segment is a clickable link.
- Show on ALL pages except the homepage.

**Tabs:**
- Use for: Related views of the same object (e.g., Overview | Activity | Settings on a project page).
- Not for: Top-level navigation or unrelated sections.

## URL Structure

URLs should mirror the IA:
```
/dashboard
/projects
/projects/[id]
/projects/[id]/settings
/settings/profile
/settings/billing
/settings/integrations
```

**Rules:**
- Use nouns, not verbs: `/projects` not `/manage-projects`.
- Use lowercase with hyphens: `/team-members` not `/teamMembers`.
- IDs should be meaningful when possible: `/projects/acme-q4` not `/projects/a1b2c3`.
- Avoid depth beyond 3 levels in the URL.

## Content Hierarchy Within Pages

Every page should answer:

1. **Where am I?** (Page title + breadcrumbs)
2. **What can I do here?** (Primary actions visible)
3. **What are the sub-sections?** (Tabs, cards, or sections)
4. **What's the most important content?** (Visual hierarchy makes this obvious)

## Page Types in SaaS

- **Dashboard:** Overview metrics + quick actions + recent activity.
- **List page:** Filterable/sortable/searchable collection. Primary CTA to create new.
- **Detail page:** Single object with all its information. Actions in header.
- **Settings page:** Grouped form fields. Save per-section, not per-page.
- **Empty state:** Explains what this page is for + single CTA to add first item.

## Search and Filtering

- Search should be accessible from everywhere (global search in header).
- Filters should be visible, not hidden in menus. Show applied filter count.
- Common filter patterns: Status, Date range, Owner, Tags/Labels.
- Saved/preset filters for common queries.
- URL should reflect filter state (`?status=active&owner=me`) for shareability.

## Information Grouping

Apply these principles (card sorting research):

1. **Group by user task, not by data type.**
   - BAD: "Images" | "Documents" | "Videos"
   - GOOD: "Marketing Assets" | "Product Specs" | "Team Resources"
2. **Limit groups to 5-9 items** (Miller's Law).
3. **Label groups clearly.** If you need to explain the label, change the label.
4. **Most-used items first.** Alphabetical is lazy architecture.

## Progressive Disclosure

Don't show everything at once:

- **Level 1:** Show the essential (list view with key columns).
- **Level 2:** Reveal on interaction (hover for preview, click for detail).
- **Level 3:** Available on demand (settings, advanced options, raw data).
- **Level 4:** Discoverable for power users (keyboard shortcuts, API, bulk actions).

## Output Format

When designing IA:

1. Map the full navigation structure (sidebar/top nav items + groupings).
2. Define URL patterns.
3. Specify page types and their content hierarchy.
4. Identify search/filter needs.
5. Note any progressive disclosure patterns.

Overview

This skill helps you design clear, predictable information architecture for SaaS apps so users find what they need without thinking. It focuses on navigation patterns, labeling, content hierarchy, URL structure, and progressive disclosure to improve findability and reduce friction. I provide practical layouts, URL rules, and page templates tailored for non-technical founders building product workflows.

How this skill works

I inspect your product goals, user tasks, and content to map a navigation structure that matches users' mental models. I recommend navigation patterns (top nav, sidebar, command palette), URL conventions, page types, and progressive disclosure rules. I also specify search and filtering needs, grouping rules, and visual hierarchy to make key actions and content obvious.

When to use it

  • You need to organize app navigation or redesign menus for clarity and scale.
  • You want to improve findability for new or power users across a growing feature set.
  • You are building URL conventions and want predictable, shareable links.
  • You need to define page templates (dashboard, list, detail, settings).
  • You want to reduce user errors caused by vague labels or deep nesting.

Best practices

  • Design navigation to match user tasks, not your org chart or DB schema.
  • Prefer flat structures; avoid more than three levels of depth whenever possible.
  • Use clear, action-neutral labels (nouns over verbs) and test them with users.
  • Make search global and show applied filters in the URL for shareability.
  • Show breadcrumbs for depth >2 and use progressive disclosure for complexity.

Example use cases

  • Map a sidebar and top-nav hybrid for a product with many features and a few global sections.
  • Define URL patterns and slug rules for projects, users, and settings pages.
  • Design a dashboard, list, and detail page template with priority actions and visual hierarchy.
  • Set up a command palette for power users and keyboard-driven workflows.
  • Create filter and saved-view conventions so teammates can share specific views.

FAQ

How deep should my navigation go?

Avoid more than three levels; prefer grouping and progressive disclosure rather than deep nesting.

What labeling rules should I follow?

Use short, familiar nouns that describe user tasks. If a label needs explanation, rename it.