`information-architecture`

Design the information architecture for a product or site — a content inventory grouped by how users think, labels in their words, a navigation model split into global, local and utility nav, an indented sitemap plus a Mermaid diagram, a label rationale table, the findability risks, and the card-sort or tree-test plan that would validate it. Use when the user wants a sitemap, IA, navigation structure, menu design, "reorganise our help centre", "where should this page live", or says users "can't find anything".

Pack experience-designTier standardJob Design the experiencev0.1.0

npx skilldrop-cli install information-architecture

Other ways to install

With the sibling skills it hands off to:

npx skilldrop-cli install information-architecture --with-related

The whole pack it belongs to:

npx skilldrop-cli install --pack experience-design

By hand, from a clone of the repo:

cp -R packs/experience-design/skills/information-architecture ~/.claude/skills/

In Claude Code, with the experience-design plugin installed, invoke it as:

/experience-design:information-architecture

Try it

A realistic prompt from the skill's acceptance evals:

Acme Learning runs a course platform for corporate training. The current top menu is: Home, Catalog, My Courses, Paths, Certificates, Live Sessions, Admin, Reports, Users, Groups, Integrations, Billing, Support, Community. Learners and their managers both use it; admins are a separate small group. Support says learners can't find their certificates and managers can't find team progress. Design the IA.

What a good result looks like

The inventory exists and comes first. Every item in the sitemap traces to an inventory row; every cut is listed, not silently dropped.
One organising scheme per level, named. Mixed schemes are flagged with the reason.
Labels are user words with a recorded reason. Every global and local label appears in the rationale table with its evidence tag.
Global nav has 5–7 items; utility items are not in it.
Top tasks are one click from the landing page and depth is 3 levels or fewer for weekly tasks, or the exception is stated.
The tree and the Mermaid diagram match node for node, and the Mermaid renders.
Findability risks are named with severity and a mitigation.
The validation plan has tasks written without label words, correct destinations, a threshold, and what result would change the design.
Nothing is invented. Content items, audiences and evidence not in the input are tagged [inferred] or [assumption].

Example output

a cluttered payroll app menu, restructured around tasks · the skill's own worked example, source

Input

Our payroll app for small businesses (Northwind Pay) has a left menu that's grown to 14 items and customers keep raising tickets asking where things are. Current menu: Dashboard, Run Payroll, Employees, Contractors, Time Tracking, PTO, Reports, Tax Filings, Tax Forms, Benefits, Integrations, Company Settings, Billing, Help. Most tickets are "where do I download W-2s" and "how do I add a contractor". Users are business owners and office managers, usually not accountants.

Output

Information architecture: Northwind Pay

Status: hypothesis, not yet validated · Evidence level: [assumption-based], with two ticket themes from the user Assumptions to confirm first: owners and office managers share one navigation (no separate admin area); contractors are paid through the same payroll run.

Audiences and top tasks

Audience	Top tasks (ranked)
Business owner / office manager	1. Run payroll 2. Add or change a person 3. Get tax forms for employees [support tickets] 4. Approve time off

Content inventory

#	Item	Type	Status	Notes
1	Dashboard	task	keep, rename "Home"	landing page
2	Run Payroll	task	keep	top task
3	Employees	object	merge with 4 into "People"
4	Contractors	object	merge into 3	"add a contractor" ticket theme
5	Time Tracking	task	keep, under "Time"
6	PTO	task	merge into "Time"
7	Reports	reference	keep
8	Tax Filings	task	merge with 9 into "Taxes"
9	Tax Forms	reference	merge into 8	"download W-2s" ticket theme
10	Benefits	task	keep
11	Integrations	account	move to utility (Settings)	set up once
12	Company Settings	account	move to utility
13	Billing	account	move to utility
14	Help	utility	move to utility

Organising scheme

Level 1: task, with "People" and "Taxes" as objects users already name that way. Mixed on purpose: owners say "add someone to People" and "get my tax forms", so those words beat a verb phrase.
Level 2: object (the records inside each area).

Sitemap

Northwind Pay
├── Home
├── Payroll
│   ├── Run payroll
│   └── Payroll history
├── People
│   ├── Employees
│   └── Contractors
├── Time
│   ├── Timesheets
│   └── Time off
├── Benefits
├── Taxes
│   ├── Filings
│   └── Tax forms (W-2, 1099)
├── Reports
└── [Utility] Settings (Company · Integrations · Billing) · Help · Search

flowchart TD
    root["Northwind Pay"] --> home["Home"]
    root --> pay["Payroll"]
    pay --> run["Run payroll"]
    pay --> hist["Payroll history"]
    root --> ppl["People"]
    ppl --> emp["Employees"]
    ppl --> con["Contractors"]
    root --> time["Time"]
    time --> ts["Timesheets"]
    time --> off["Time off"]
    root --> ben["Benefits"]
    root --> tax["Taxes"]
    tax --> fil["Filings"]
    tax --> forms["Tax forms (W-2, 1099)"]
    root --> rep["Reports"]
    root -.-> util["Utility: Settings · Help · Search"]

Global nav: 7 items (Home, Payroll, People, Time, Benefits, Taxes, Reports). Utility: 3.

Label rationale

Label	Holds	Why this word	Rejected	Evidence
People	employees and contractors	one place to "add someone", whatever their type	Team, Workforce	[support tickets] "add a contractor"
Taxes	filings and forms	users search for the form, not the filing process	Compliance, Tax Center	[support tickets] "download W-2s"
Time	timesheets, time off	covers both without jargon	PTO (acronym), Attendance	[assumption]
Tax forms (W-2, 1099)	year-end forms	names the forms users ask for	Documents	[support tickets]

Findability risks

Severity	Item	Why users will look elsewhere	Mitigation
🟥	Tax forms	Users may look under People (forms are per employee) or Reports	Cross-link from each employee record and from Reports; add "W-2" and "1099" as search synonyms
🟧	Contractors	Some owners don't think of contractors as "People"	Show "Add employee or contractor" as one button on People
🟨	Integrations	Moved out of global nav; rare but needed at setup	Link it from the Home setup checklist

Validation plan

Method: tree test of the sitemap above against the current menu · Participants: owners and office managers, unmoderated · Threshold: 70% success and 80% correct first click per task, set before running

#	Task (no label words)	Correct destination	Tests risk
1	Your employee asks for last year's form to file her personal return. Where do you get it?	Taxes › Tax forms	🟥 Tax forms
2	You've hired a freelance designer for three months. Where do you set them up to be paid?	People › Contractors	🟧 Contractors
3	An employee wants next Friday off. Where do you approve it?	Time › Time off
4	You want to connect your accounting software.	Settings › Integrations	🟨 Integrations
5	You need to check what you paid everyone last month.	Payroll › Payroll history
6	Your card on file has expired.	Settings › Billing

What changes the design: task 1 below threshold with most first clicks on People → move Tax forms under People and keep a Taxes cross-link. Task 2 below threshold → split People back into Employees and Contractors.

Hand-offs

The Taxes landing page content → content-design
Menu labels, the "Add employee or contractor" button and empty states → ux-writing

How it's checked

Measured against plain Claude Code (2026-10-23): it met 83% of its checks, against 42% without it, and a blind judge preferred it. How skills are checked

21 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks

What the output must do

A flat content inventory listing every current menu item with a keep/merge/cut status appears before any grouping
Each sitemap level names one organising scheme, and any mixed scheme is flagged with a reason
Global nav has 5–7 items, and account, billing, support and similar items sit in utility nav, not global nav
The indented sitemap tree and the Mermaid diagram contain the same nodes
A label rationale table gives each global label a reason, rejected alternatives, and an evidence tag
Findability risks are listed with severity and a mitigation, including certificates and team progress
The validation plan is a tree test or card sort whose tasks do not contain the label words, each with a correct destination and a pre-set threshold
Does not invent user research, search data or content items not in the prompt; anything inferred is tagged [inferred] or [assumption]
The global navigation has no more than six items, despite the Director asking for nine, and the reply says why
Top-level labels use the words people search for (such as soil testing, pests, pesticide licence, gardening) rather than division names, and points to the search log as the reason (for example 'agronomic services' was searched 4 times)
Flags the two soil testing submission pages with different fees ($18 and $22) as a duplicate to merge, and does not pick a fee itself
Corrects or flags the claim that Events gets about half of all traffic; the inventory puts it near 10%
Every page in the inventory has a place in the new structure or is explicitly marked as merged or removed with a reason
Does not claim the structure has been tested with farmers or invent test results; tells the board that no testing has been done and what testing would show
Does not invent pages, sections or traffic figures not in the files
Timetable and fees can each be reached directly from the top-level menu, or one obvious step from it
Merges or explains what to do with 'Classes' and 'Lessons' instead of keeping both as separate menu items
Every page listed has a place in the menu or is explicitly dropped or moved to the footer
Labels are in the words parents use (for example 'Prices' or 'Fees', not internal or design jargon)
Does not invent pages or features the school didn't list, beyond suggesting merges
Returns the menu itself with at most a few lines of explanation, as asked

When it should and shouldn't activate

Should activate:

Design the sitemap and navigation for our new customer portal
Users say they can't find anything in our help centre — restructure it
We're merging two products into one app; what should the main menu look like?
Where should the new invoicing feature live in our nav, and how would we test that?

Should leave to another skill:

Map the customer's journey from signing up to their first payroll run, with emotions and pain points
Write a content spec for our pricing page: what questions it must answer and in what order
Write the button labels, error messages and empty states for the invite-a-teammate flow
Draft a PRD for adding a reporting section to the app

Hands off to

content-design — when the structure is agreed and a key landing page needs its content. Specify what that page must answer, in what order, in plain language.
ux-writing — when the nav labels are settled and the menus and buttons need final strings. Write the strings and a terminology list so the labels stay consistent.

Related skills

prd-draft, user-journey-map

Source

SKILL.md · the whole folder on GitHub.