Information Architecture Process: Six Stages from Scoping to Maintenance
By UXbeam · Information architecture tools since 2021
Information architecture work doesn't always start with a card sort or end when a sitemap is finished. You may need to diagnose an existing structure, build a new one, or revisit a decision after launch. These six stages show where each kind of work fits.
The process addresses four information architecture systems: organization, labeling, navigation and search. The information architecture overview explains each. Short on time or people? See a smaller version of the process.
The process at a glance
Choose whether you're building something new or improving an existing structure. The guidance changes with your choice, but all six stages remain available.
- Decide and scopeIs the work needed, and what is it for?
- Discover and assessWhat do people need, and what exists?
- Organize and labelHow should content be grouped and labeled?
- Test and refineCan people find things through the structure?
- Translate into designHow does the structure become screens?
- Launch, measure and maintainHow will the structure stay useful?
- From stage 4 back to stage 3: test paths suggest a grouping or labeling problem that needs investigation.
- From 6 back to 2: after launch, new content, searches or support questions show gaps the structure does not cover.
Select a stage to see what it decides and produces, or read the stages below.Tap a stage to go to its section.
Decide and scope
Is structural work needed, and what is it for?
- Decides
- Whether IA work is needed, which parts can change, who has the final say and what evidence would settle the decision.
- Produces
- A written decision, clear boundaries, a named decision-maker and, when testing, criteria for keeping or changing the structure.
- Building something new
- List what the product must contain or let people do, and the decision the structure must settle, such as which main sections to have and what to call them.
- Improving something that exists
- Start from symptoms you already see, such as support questions, search terms and complaints, and check whether the structure is the problem at all.
- Complete when
- The decision-maker has agreed the question and scope, and any planned evaluation criteria are recorded.
Before choosing a method, write down the decision you need to make and what the team can change. “Make things easier to find” is too broad to test. Name the priority tasks instead, then decide what results would persuade you to keep or revise the structure. For an existing product, the triage in the information architecture assessment helps you tell a structural problem from a content, interface or search problem.
What to prepare before you start
- Analytics, site-search logs and support or enquiry data, if available.
- A list of the pages or screens you have, or of the features you plan.
- What the platform or content management system can and cannot change.
- People who can take part in studies, from each audience the decision affects.
- The person who can resolve disputed placements.
Agree how you will judge the results
Before testing a candidate, agree what would make you keep it, change it or test another version. Otherwise it's easy to explain away results that challenge a preferred structure. Exploratory research starts with an open question; it doesn't need a pass mark. See “Deciding when you have enough evidence” for the stopping rule.
Library example (illustrative)
The example follows the fictional city library site from information architecture deliverables, using the same item IDs: INV- for inventory rows, N- for structure nodes, T- for taxonomy terms and D- for decisions. The decision: how to organize the top level of the site and where each existing page goes. New top-level sections need the web steering group's approval, as the governance rules in that example record.
Discover and assess
What do people need, what exists, and what is missing?
- Decides
- Which tasks matter most, which content and features the structure must hold, where the current structure fails, and what is still unknown.
- Produces
- Research inputs with sources and dates, a priority-task list, a content inventory and audit where coverage is in question, a baseline for an existing structure, and a list of open questions.
- Building something new
- Start with business goals, user needs, and the content and features planned. Inventory anything already drafted.
- Improving something that exists
- Measure the current structure before changing it, with tasks you can reuse later, and inventory what exists when coverage or duplication is in question.
- Complete when
- The team agrees on priority tasks, identifies the content each requires and assigns owners to any gaps. The questions still needing research are recorded.
Evidence and methods
| Evidence | Tells you | Cannot tell you |
|---|---|---|
| Analytics and site-search logs | Entry pages and navigation paths where tracked, common search terms, and searches that return no results. | Why people searched, or whether browsing failed first. |
| Support tickets and enquiries | Recurring problems, described in people's own words. | How common a problem is among people who never contact you. |
| Top-tasks research | Which small set of tasks matters most to the people you serve. | How to group or label the content for those tasks. |
| Content inventory and audit | What exists, and what should happen to each item. | How people expect the content to be grouped. |
| Baseline tree test (existing structure) | How findable priority items are in the current structure, task by task. | The precise cause of a failure, or how the interface affects performance. |
Check available content and features against priority tasks. Record missing content as a gap; rearranging pages cannot create it. Use an inventory when you need to assess coverage or duplicates. If you are migrating an existing site, also list every affected URL so moves, merges, retirements and redirects can be planned. For an app, inventory the relevant screens and features.
Move on when
- Each priority task maps to content, or its gap is recorded with an owner or a decision.
- Each open question names a user need, disputed item or label that a study could investigate.
Go back to stage 1 if
- The evidence points to a content, interface or search problem rather than a structural one.
Library example (illustrative)
The inventory shows two pages answering the same question: INV-001 "Opening hours" and INV-002 "Hours and locations", with summer hours out of date on the second. INV-004, a 2019 renovation update, serves no current task. Site search shows people typing "story hour" for events the library calls "Storytime".
Organize and label
How should content be grouped, and what should the groups be called?
- Decides
- The organizing principle, the groups, the labels people understand, and which candidate structures to test.
- Produces
- A candidate structure, with alternatives where a choice is unresolved, preferred terms with the variants people use, and the reasons behind each decision in a decision log.
- Building something new
- When grouping or terminology is uncertain, an open card sort can help show how participants group items and name those groups.
- Improving something that exists
- A closed sort tests placement into categories you provide. A hybrid sort also lets participants introduce categories that are missing.
- Complete when
- You have at least one candidate structure backed by evidence and labeled with words people use, plus alternatives where a real choice is still open.
Evidence and methods
| Method | Tells you | Cannot tell you |
|---|---|---|
| Open card sorting | How participants group items, and the names they give the groups. | Whether people can find items in the structure you build from it. |
| Closed card sorting | Where people place items among categories you supply, and how strongly they agree. | Whether the categories are the right ones. |
| Hybrid card sorting | Where participants use supplied categories and where they propose new ones. | Whether people can find items in the resulting structure. |
Research can show how people group content, but someone still has to choose the organizing principle. That choice might be topic, task, audience or a mix. Use a card sort to explore the options, then test whether a candidate hierarchy helps people complete the tasks that matter.
When participants sort the same content in different, consistent ways, you can draft separate candidate structures and compare them using the same tree-test tasks.
When several audiences or roles use the same product, one option is a structure built around shared tasks with a separate section only where an audience's needs differ; another is separate entry points per audience. Sketch both options and test them instead of settling the argument in a meeting. Use the language people used in research for label candidates, and keep internal terms as search synonyms where useful.
Move on when
- The candidate, and any alternative, is complete enough to test the priority tasks.
- Every disputed placement is written down as a question the test can answer.
Go back to stage 2 if
- Items keep landing nowhere because the content behind them is unclear or missing.
Library example (illustrative)
Decision D-01: organize the top level primarily by task, with one audience-specific section, Kids and teens, for services that do not fit the shared tasks. The preferred term is "Storytime" (T-11), with "story hour" kept as a variant for search. One placement stays open: decision D-03, where help for e-books belongs (N-1.3), because the owners disagree.
Test and refine
Can people find things through the structure?
- Decides
- Whether a candidate works for the priority tasks, which candidate to keep, what to change, and whether another round is needed.
- Produces
- Findings for each task, a revised structure, and decision-log entries that close the open questions or record why they stay open.
- Building something new
- You can test before anything is designed: a tree test uses the labels alone.
- Improving something that exists
- To compare two hierarchies, test the same user goals against both. Keep the wording consistent when you need to isolate the effect of the hierarchy.
- Complete when
- The evidence supports a decision to keep or revise the structure, or the decision-maker accepts what is still uncertain.
Evidence and methods
| Method | Tells you | Cannot tell you |
|---|---|---|
| Tree testing | Where participants go in a text-only hierarchy, whether they reach the intended destination, and the paths they take for the tested tasks. | How layout, visual design or search in the real interface change the result. |
A tree test tells you how participants navigated the tasks you gave them, not which hierarchy will work best for everyone. If task wording changes between versions, document it: the results may still guide a decision, but the difference cannot be attributed to the hierarchy alone.
What you ask participants to do determines what you can learn. Write tasks around real user goals without giving away the destination's label. For examples, see writing task instructions and leading tasks in tree testing. The assessment's method table covers when another method answers the question better.
Move on when
- The results meet the criteria agreed before testing.
- What remains uncertain is recorded, with what it would take to settle it.
Go back to an earlier stage if
- Stage 3: wrong destinations or repeated detours may suggest a grouping or label problem; investigate that explanation before revising the structure.
- Stage 2: the findings reveal missing content.
Library example (illustrative)
The open placement D-03, help for e-books (INV-006, node N-1.3), becomes a task that avoids the words in the labels:
You want to read a library title on your tablet tonight. Where would you find out how to set that up?
Testing candidate placements with the same task would show where participants first go, which paths they take and where they finish. Those observations could inform decision D-03. This fictional example does not supply results or claim a winning placement.
Translate into design
How does the structure become navigation and screens?
- Decides
- Which parts of the structure appear in which navigation, what each screen must hold, and what search returns for the words people use.
- Produces
- A sitemap or structure specification, a navigation specification, search synonyms and low-fidelity wireframes.
- Building something new
- Hand the tested structure to design with the decisions and open questions attached.
- Improving something that exists
- For affected content, record what moves, merges, remains or retires, with redirect mappings where URLs change.
- Complete when
- Design accepts the handoff: the structure, its labels, the navigation rules and the open questions.
A sitemap gives you structure, not a finished interface. From sitemap to wireframe covers the choices a sitemap can't make: which navigation controls to use, what appears first on a screen and how someone moves through a task. Record those choices in a navigation specification, and keep search synonyms for the words people use.
First-click testing looks at the first choice people make on a layout or prototype. It sits where structure meets interface: a poor result can come from the label, its screen position or its visual treatment. If a comparable tree-test result exists, read the two together.
Move on when
- The handoff checklist is complete and design has accepted it.
Go back to stage 4 if
- A design constraint forces a structural change: test the changed part again.
Library example (illustrative)
The global navigation shows the six top-level sections, N-1 to N-6. Search maps "story hour" to Storytime (T-11). The migration map merges INV-001 and INV-002 into "Hours and locations" (N-2.1) and retires INV-004.
Launch, measure and maintain
How will the structure stay useful?
- Decides
- How content and links move to the new structure, what to watch after launch, who may change the structure, and when to revisit decisions.
- Produces
- An implementation or handoff plan, redirects where addresses move, an owner for each part of the structure, governance rules, a decision log kept up to date, and a plan for measuring again.
- Building something new
- Set owners and rules for adding sections and terms before content starts to grow.
- Improving something that exists
- Record what happens to each affected page or screen, redirect changed URLs where needed, and compare post-launch findings with any available baseline.
- Complete when
- The next review is scheduled and the events that would trigger an earlier one are recorded.
Launch and migration
Record what happens to affected content: what remains, moves, merges or retires. Redirect changed URLs where needed, keep important old terms findable through search, and brief support teams before consequential changes go live.
Measure after launch
After launch, repeat the priority tasks where a fair comparison is possible. If the wording or method changed, say so rather than presenting the scores as a clean before-and-after. Also watch what people search for, which searches fail and what problems appear in support requests. Review sooner when those patterns change.
Maintain the structure
New pages, services and labels keep arriving after launch. Without clear ownership, teams start adding sections or renaming categories case by case. Your decision log and governance rules should record why changes were made, who can approve them and when a wider review is needed.
Signs the structure is holding
- Re-measured tasks hold or improve, and new content finds a home under the rules.
Go back to stage 2 if
- New content, searches or support questions show gaps the structure does not cover.
Library example (illustrative)
Any team may propose a new top-level section; the web steering group approves it, records it in the decision log and reviews it before the section launches. Decision D-01 is to be revisited if a new audience-only service area is added.
Deciding when you have enough evidence
There is no universal pass mark. The question is whether remaining uncertainty could change the decision. Use the checks below to decide whether another round would help.
- For evaluations, use the decision rule agreed at the outset. Identify the tasks or outcomes that matter and which structures, if any, are being compared.
- When comparing structures, distinguish evidence about the hierarchy from evidence about the task wording. Record any changes to the tasks so readers know what can and cannot be compared.
- Read mixed results by task. One candidate can be better for some tasks and worse for others. Decide task by task, and test a combined structure if the strengths sit in different places.
- Record what stays uncertain. When another round would not change the decision, stop, and write down the doubt and the evidence that would settle it.
How many participants and tasks a study needs depends on what you need to claim; the information architecture assessment sets out the guidance and its limits.
A smaller version of the process
With a small team or a short deadline, keep the decisions and shrink the studies. Start with what you already have.
| Stage | Essential | Can shrink | What you lose |
|---|---|---|---|
| 1 Decide and scope | The one-sentence decision, a named decision-maker, and an evaluation rule when needed | Formal success measures | A reliable basis for judging whether the change helped people complete their priority tasks |
| 2 Discover and assess | Priority tasks and existing evidence; for a migration, all affected URLs | A full inventory beyond the tasks and affected URLs | Content gaps or duplicates outside the scope you reviewed |
| 3 Organize and label | At least one written candidate structure, labeled with people's words | Card sorting, if the groups are not in dispute | Evidence for groupings people would choose themselves |
| 4 Test and refine | Evidence on the structural question, from a method that fits it: a tree test when the question is whether people can find things in the hierarchy | Extra rounds and second candidates | A comparison of alternative structures and evidence on whether later refinements improved outcomes |
| 5 Translate into design | The structure and labels handed to design with open questions | A separate navigation specification | Consistency when several people build the navigation |
| 6 Launch, measure and maintain | A planned implementation or handoff, a named owner, and redirects or a migration when addresses move | A full governance document | Protection against drift as content grows |
What makes the work take longer
- The size of the content or feature set, and how many teams own parts of it.
- How many audiences or roles need separate evidence.
- How long reviews and approvals take, and how many decision-makers there are.
- How hard it is to recruit participants from each audience.
- How many rounds of testing the decision rule requires.
Doing it yourself or bringing in help
A small team can run a card sort or tree test without specialist support. Get an experienced review when task wording might lead participants, results point in different directions or the decision would be expensive to undo.
Where to go next
- Information architecture assessmentEvaluate an existing structure using the evidence you have, and decide what to test next.
- Information architecture deliverablesSee the artifacts an IA project needs, with examples and reusable templates.
- Card Sorting GuideDiscover how people group and name your content. Explore open, closed and hybrid card sorting, analyze the results, and use the findings to inform a sitemap.
- Tree Testing GuideCheck whether people can find things in a structure, using text-only labels and realistic tasks, before any design exists.
- From sitemap to wireframeTurn a tested sitemap into navigation, screen priorities and task paths.
- Organizing principlesWhen the rule itself is in question: should this be organized by topic, by task, by audience or by life event?
- From card sorting to sitemap to tree testingUse card sorting to explore groups and labels, then tree testing to check whether people can find things.
Sources
- Kaley, A. "Content Inventory and Auditing 101." Nielsen Norman Group, 2020.
- Farrell, S. "Site-Search Log Analysis." Nielsen Norman Group, 2017.
- Wiggins, R. and Rosenfeld, L. "Using Search Analytics to Diagnose What's Ailing Your Information Architecture." IA Summit, 2007.
- Canada.ca Experience Office. "How we're optimizing Canada.ca top tasks." 2017.
- Wake, L. "Top task performance indicators." University of St Andrews Digital Communications, 2017 (reporting Gerry McGovern's method).
- Tankala, S. and Sherwin, K. "Card Sorting: Uncover Users' Mental Models for Better Information Architecture." Nielsen Norman Group, 2024.
- Spencer, D. and Warfel, T. "Card Sorting: A Definitive Guide." Boxes and Arrows, 2004.
- Laubheimer, P. "Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories." Nielsen Norman Group, 2023.
- O'Brien, D. "Tree Testing." Boxes and Arrows, 2009.
- Kuric, E., Demcak, P. and Krajcovic, M. "Validation of information architecture: cross-methodological comparison of tree testing variants and prototype user testing." Information and Software Technology.
- Sauro, J., Schiavone, W., Du, D. and Lewis, J. "Do Click Tests Predict Live-Site Clicks?" MeasuringU, 2023.
- Mann, D. "The art of redirection." Inside GOV.UK, 2014.
- Nygard, M. "Documenting Architecture Decisions." 2011.