information_architecture v1.0.0

name: "information_architecture" description: "Structure a site or app so people find things: run a content inventory and audit, choose organization schemes and navigation models, write and audit labels, build a taxonomy that works with search, and prove the structure with card sorting and tree testing. Ships inventory and labeling audit templates, audit and scoring CLIs, and a worked site map rebuild. Use when navigation confuses users, content is duplicated or homeless, a redesign needs a site map, or findability has to be tested before building."

Purpose

Information architecture is the structural design of a site or app: how content is grouped, labelled, and reached, so users can tell where they are, what they have found, and where to go next. The classic model from Rosenfeld, Morville, and Arango has four parts: organization systems, labeling systems, navigation systems, and search systems. Work all four. A pretty menu over a broken grouping still fails.

This skill ships tools, not just advice: bin/ia_audit.py audits an inventory CSV, bin/card_sort_pairs.py reads card sort placements, bin/tree_test_score.py scores a tree test, templates sit in assets/, full test protocols are in references/test-protocols.md, and a complete before and after rebuild is in references/worked-sitemap-rebuild.md.

Workflow

1. Inventory what exists

• Crawl or export every page, screen, and document into the inventory template at assets/content-inventory-template.csv: URL, title, owner, content type, audience, primary task, last reviewed date, decision, nav parent, nav label.
• Audit the inventory qualitatively on top of the list: is each item accurate, still needed, duplicated elsewhere, or answering a question nobody asks anymore. Give every row a decision: keep, revise, merge, or retire. Retire and merge are decisions someone has to own, so name the owner per row.
• Run python3 bin/ia_audit.py inventory.csv and fix what it surfaces before designing anything: duplicate URLs and titles, missing owners, the same label pointing at different places, orphan parents, stale pages, and sections with one child or a crowd of children.

2. Pick the organization scheme

• Choose the scheme from how users think about the content, not from the org chart. Exact schemes suit known item lookup: alphabetical, chronological, geographical. Ambiguous schemes suit browsing: topic, task, audience, metaphor, or a hybrid.
• Topic is the safest default for a mixed content set. GOV.UK runs its taxonomy on topic alone: what the content is about, not which department published it, not its format, not who it is for. Department and format schemes are the most common cause of "I looked in the obvious place and it was not there".
• Mix schemes only at different levels or with clear signposting. Topic at the top with a task based section for a multi step service is fine. Topic and audience side by side at the same level forces users to guess which door the site builder meant.
• Balance breadth and depth instead of chasing either one. As a working range, GOV.UK aims for 2 to 12 child topics per topic: a topic with one child usually means the child should merge up or move up, and a level past a dozen options is hard to scan. Treat that as a review prompt, not a law. There is no verified rule that everything must sit within three clicks; depth hurts when labels get weak, not at a magic click count.

3. Build the navigation model

• Layer the navigation types instead of asking one menu to do everything:
• Global: the top level sections, present everywhere, worded in the users' terms.
• Local: navigation inside a section, for its subsections and sibling pages.
• Contextual: links inside content to the specific next thing that content implies.
• Supplemental: sitemap, A to Z index, and guides, which catch the people the hierarchy failed.
• Utility: account, search, contact, and similar tools, kept out of the content hierarchy.
• Show users where they are: current section highlighted, breadcrumbs on anything deeper than one level, and a page title that matches the label they clicked to get there.
• Keep the global list short enough to scan at a glance. If a top level item only exists because a department demanded a door, it belongs in the footer or a section, not the global nav.

4. Write labels, then audit them

• Labels carry the whole structure. A user following a label is betting the content behind it matches the word. Write labels from user language first: search queries, support tickets, card sort group names. Internal names, project codenames, and department names fail this test by default.
• Apply the rules in assets/labeling-audit-template.csv to every nav and section label:
• One label, one destination. Never reuse the same words for two different places.
• Labels at the same level must be distinguishable at a glance. Products, Solutions, and Resources side by side tell users nothing about how they differ.
• Link text must make sense out of context. "Change bank details" works alone, "Click here" and "Change" do not.
• Keep style consistent across a level: same grammar, same casing, same length range. Mixed styles read as mixed meaning.
• Prefer plain text labels over icons alone for anything that is not a near universal symbol.
• Scent test each label: could a first time user predict, from the word alone, roughly what sits behind it and what does not. If not, the label is decoration.

5. Make taxonomy and search work together

• Treat the taxonomy as data, not just a diagram: each category gets a definition, inclusion and exclusion rules, and an owner. New content gets placed by the rules, not by whoever shouts loudest that week.
• Build a small controlled vocabulary for tags and metadata: preferred term, accepted synonyms, and terms to avoid. Search maps the synonyms onto the preferred term so "refund", "money back", and "chargeback" reach the same policy.
• Mine search logs on a regular cadence: top queries with no clicks, and queries returning zero results, are a findability bug list written by users. Fix them in this order: missing content, missing synonym in the vocabulary, wrong label, wrong category.
• Do not use search as an excuse for a weak structure. Many users browse first and search only after browsing fails, and search results still need clear titles and section context to be trusted.

6. Prove it with a card sort, then a tree test

• When the grouping is in question, run a card sort before drawing the site map. Open sort to discover groups, closed sort to check placement into settled categories, hybrid when the top level is mostly settled. About 15 participants per audience is where the grouping pattern stabilizes; use the protocol and analysis steps in references/test-protocols.md and score placements with python3 bin/card_sort_pairs.py placements.csv.
• When a draft structure exists, tree test it before building: participants navigate a text only tree to complete scenario tasks, so labels and grouping are tested with no visual design to hide behind.
• Score with python3 bin/tree_test_score.py results.csv. Read results against the Albert and Tullis bands reported by Nielsen Norman Group from 98 studies: task success under 40 percent is Poor, 41 to 60 Fair, 61 to 80 Good, 80 to 90 Very Good, over 90 Excellent, with a cross study median of 62 percent.
• Diagnose before redesigning: a wrong first click for most participants points at a top level label problem, good success with low directness points at a weak intermediate label, and one dominant wrong destination means that destination's label overpromises. Full diagnosis patterns are in references/test-protocols.md.
• Change one structural thing at a time and retest the failed tasks. Report before and after scores per task, the way references/worked-sitemap-rebuild.md does.

7. Govern the structure after launch

• Assign an owner to the taxonomy and to each top level section. Unowned structures drift within a quarter.
• Gate new top level items: a new global nav entry needs evidence of a top user task behind it, and something else usually has to leave to keep the list scannable.
• Re-run the inventory audit on a fixed cadence, quarterly for a fast changing site. Watch for the early drift signs the audit catches: new duplicate titles, labels reused for new destinations, and sections quietly growing a thirteenth child.

Output Contract

Deliver, scaled to the size of the job:

1. The content inventory with a decision and an owner per row, plus the ia_audit.py findings and what was done about each.
2. The proposed structure as a site map or tree, with the organization scheme named and the reason it fits the users.
3. The labeling audit table: every global and local label, problems found, and the replacement wording.
4. The taxonomy rules for the top levels: category definitions, inclusion and exclusion rules, and the controlled vocabulary for search synonyms.
5. Test evidence: card sort agreement findings and tree test scores per task, before and after any change, with the fixes each failure produced.
6. A governance note: who owns the structure, what the gate is for new top level items, and when the next audit runs.

Operating Rules

1. Verify every number you cite. The sample sizes, success bands, and taxonomy ranges in this skill trace to NN/g, the Tullis and Wood card sort study, Albert and Tullis, and GOV.UK guidance. Do not invent thresholds, click rules, or menu size laws beyond those sources.
2. Never organize by org chart, department, or content format unless evidence shows users think that way too.
3. A site map is an output, not the work. The work is the grouping, the labels, and the test evidence behind them.
4. Do not ship an untested structure for a high traffic or high stakes site when a tree test was possible. Say plainly in the report when testing was skipped and why.
5. Keep one home per content item in the structure. Cross links and search synonyms handle the second place users look; duplicate pages split ranking, ownership, and updates.
6. Write labels in the users' words, and test them. A label the team loves that users misread is a wrong label.