Information Architecture
Define navigation, page hierarchy, URLs, and user flows after a design brief and before you or your agent starts building pages.
Overview
Information Architecture is an agent skill most often used in Validate (also Build frontend, Build docs) that defines navigation, hierarchy, URLs, and user flows before visual design and coding tasks begin.
Install
npx skills add https://github.com/julianoczkowski/designer-skills --skill information-architectureWhat is this skill?
- Runs after DESIGN_BRIEF.md and before task breakdown—explicit gap between brief and build
- Scans existing routing (Next app/pages, React/Vue/Svelte routers, static HTML) and nav/layout components
- Covers navigation, content hierarchy, page structure, URL patterns, and onboarding-style user flows
- Example prompts for docs sites, app IA, and onboarding flow mapping
- Resolves multiple `.design/*/DESIGN_BRIEF.md` folders by recency or user choice
Adoption & trust: 2.2k installs on skills.sh; 269 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a product idea or brief but no agreed map of pages, nav, and paths—so every build session risks inconsistent routing and lost users.
Who is it for?
Solo builders shipping SaaS, docs, or multi-page apps who already have or are writing a design brief and want structure before components.
Skip if: Pure visual mood-board work with no pages yet, or one-screen utilities where routing and IA are trivial.
When should I use this skill?
User wants to plan site structure, define navigation, map user flows, organize content, or mentions IA or information architecture—after brief, before tasks.
What do I get? / Deliverables
You get a coherent structural plan aligned to your brief and codebase so the next step is scoped implementation tasks or UI work without re-litigating site shape.
- Navigation and page hierarchy plan
- URL and routing conventions
- Documented user flows for key journeys
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Information architecture is the structural contract you prove in Validate—how content and routes fit the product—before committing engineering tasks in Build. Scope subphase is where solo builders lock page types, nav depth, and flows so the MVP surface area stays honest.
Where it fits
List MVP pages, nav tiers, and onboarding flow before estimating build time.
Align new feature routes with existing header and layout components in the repo.
Restructure a docs tree with stable URL patterns before writing MDX pages.
Sketch how a multi-section marketing plus app shell could connect without building yet.
How it compares
Use for structural planning after a brief—not as a color or component styling reference skill.
Common Questions / FAQ
Who is information-architecture for?
Indie developers and small teams using Claude Code, Cursor, or Codex who need clear nav, URLs, and flows before agents generate pages.
When should I use information-architecture?
In Validate when scoping MVP pages and flows; in Build frontend when refactoring routes or nav; in Build docs when organizing a documentation site—always after the brief, before tasks.
Is information-architecture safe to install?
It guides planning and codebase exploration; review the Security Audits panel on this Prism page before installing any skill from the repo.
SKILL.md
READMESKILL.md - Information Architecture
This skill defines the structural skeleton of a product or site. It sits between the design brief and the build. Run this after the brief is written and before tasks are created. ## Example prompts - "Plan the IA for this app before I start building" - "Map out the navigation and page structure" - "I need to organize the content for a documentation site" - "Define user flows for the onboarding experience" ## Process 1. Look for an existing design brief at `.design/*/DESIGN_BRIEF.md`. If multiple subfolders exist, use the most recently modified one, or ask the user which feature they are working on. If no brief exists, ask the user what they are building and for whom. 2. Explore the existing codebase to understand what structure already exists: - **Routing**: Next.js `app/` or `pages/` directory, React Router config, Vue Router, SvelteKit routes, or static HTML page files - **Navigation components**: header, sidebar, navbar, breadcrumb, footer components - **Layout components**: root layouts, nested layouts, page wrappers, container components - **Page directories**: how pages are currently organized in the file system - **URL patterns**: existing slugs, dynamic segments, query parameter conventions - **CMS or data layer**: content models, API routes, data fetching patterns, MDX/content directories - If structure exists, this skill extends and improves it. Do not propose a new architecture that ignores what is already built. 3. Interview the user about structural decisions. For each question, provide your recommended answer. Cover at minimum: - What are the primary things a user needs to find or do? Rank by frequency. - How many levels of navigation depth are acceptable? - What content will grow over time vs. what is fixed? - Are there distinct user types who need different entry points? - What is the one page/view where the user spends 80% of their time? 4. Once you have a shared understanding, produce the IA document using the template below and save it as `INFORMATION_ARCHITECTURE.md` in the same `.design/<feature-slug>/` subfolder as the design brief. ## IA Document Template ```markdown # Information Architecture: [Product/Site Name] ## Site Map A hierarchical map of every page or view. Use indentation to show nesting. Include the URL pattern for each. - Home `/` - Feature A `/feature-a` - Sub-page `/feature-a/detail` - Feature B `/feature-b` - Settings `/settings` - Profile `/settings/profile` ## Navigation Model Describe the navigation system: - **Primary navigation**: What appears in the main nav? Maximum items. - **Secondary navigation**: Sidebar, tabs, or contextual links within sections. - **Utility navigation**: Account, settings, help, and anything outside the main content hierarchy. - **Mobile navigation**: How navigation adapts. Hamburger, bottom tabs, or something else. ## Content Hierarchy For each major page or view, define the content priority: ### [Page Name] 1. [Highest priority content] -- Why this comes first 2. [Second priority] -- Why this comes second 3. [Third priority] -- Rationale 4. [Below the fold / secondary] ## User Flows The critical paths through the product. Each flow is a sequence of steps with decision points noted. ### [Flow Name] (e.g., "New user onboarding" or "Create a project") 1. User lands on [page] 2. User sees [content/prompt] 3. User takes action: [action] - If [condition A] -> [outcome] - If [condition B] -> [outcome] 4. User arrives at [destination] ## Naming Conventions A glossary of terms used in the interface. Consistency matters. Pick one word an