How to Conduct a Task-Based Information Architecture Audit

Audit representative tasks and every plausible route to their outcomes before judging menus or drawing a new sitemap. Start with a consequential job a customer, partner, applicant, or staff member needs to complete, then follow it from realistic entry points through browse navigation, contextual links, internal search, and the final page or action. That record reveals whether the actual break is structural or a more bounded problem with content, wording, linking, search, or interaction.

A crowded menu, a high-exit page, or a run of complaints can justify investigation, but none identifies the cause on its own. Without task-level evidence, a New Zealand organisation can commit redesign or migration budget while leaving the important journey unimproved. The useful output is therefore not a tidier diagram. It is a traceable account of who needed what, which routes were available, what happened, why the route failed, and what should be tested next.

What decision should your IA audit inform?

Design the audit around one bounded decision: whether to repair a section, change labels, prepare a migration, or investigate the case for wider structural change. Information architecture covers organisation, labels, and navigation that help people find information, understand where they are and what they can do next, and complete intended tasks. A task-based audit examines how that route system supports selected outcomes; it does not begin by assuming the whole structure is defective.

Write down the included audiences, goals, starting contexts, page types, devices, locales, permissions, and journey states. A finding from a public desktop journey may not apply to an authenticated mobile experience, and a route that works for an experienced staff member may remain opaque to a first-time customer. Keep known facts, behavioural observations, expert inspection findings, and untested hypotheses in separate fields so confidence does not rise merely because a statement has been repeated.

• Decision: the approval, repair, migration, or redesign question the evidence must answer.
• Scope: the users, tasks, contexts, routes, and states included in the audit.
• Standard: the evidence needed before a concern becomes a finding or a recommendation.
• Boundary: related work that belongs in a content inventory, technical SEO audit, accessibility conformance evaluation, or redesign.

How do you build a representative task set from evidence?

Build the task set from evidence about what people are trying to achieve, how they currently approach it, where they encounter problems, and what outcome they need. Write each task in language its audience would recognise, without naming the destination or revealing the expected navigation choice. “Find out whether our organisation can apply and what information we need” is a usable outcome; “go to Eligibility” quietly supplies the answer the audit is meant to examine.

Use a mix of prior research, interviews, observation, analytics, internal-search queries, support demand, feedback, and staff who work directly with users. These inputs have different strengths. A search query records language and behaviour, not necessarily intent; an exit records an event, not its cause. Stakeholder statements and expert assumptions can nominate tasks, but label them as hypotheses until evidence from intended users supports them. A documented Digital.gov study similarly derived realistic scenarios from prior research and reviewed their coverage before testing.

• Balance frequent tasks with consequential, difficult, and underserved tasks.
• Record the audience, trigger, starting contexts, intended outcome, destination, and evidence source.
• Note whether the task is evidenced, inferred, or still hypothetical.
• Check the complete set for material gaps rather than filling it with easy variations of one journey.

What should the task-to-route worksheet capture?

The worksheet should connect each evidenced task to its intended outcome, realistic starting contexts, plausible routes, inspected cues, observed behaviour, diagnosis, recommendation, owner, and retest. Use one record throughout the audit rather than producing separate inspection, research, and prioritisation documents that cannot be reconciled. Start from contexts people may actually encounter: an external landing page, a section page, an authenticated portal, a bookmarked page, or an internal-search result—not only the home page.

Map browse, contextual-link, and search routes wherever they are plausible. At every decision point, capture the visible cue, the expectation it creates, the destination reached, and whether someone can recognise and recover from a wrong choice. The WCAG 2.2 Multiple Ways success criterion requires more than one way to locate most pages in a set, with an exception for results or steps in a process; documented approaches include related links, site maps, search, and comprehensive navigation.

1. Define the successful outcome and destination.
2. List the starting contexts and each plausible route.
3. Record labels, headings, groupings, cross-links, search queries, and recovery cues.
4. Attach observations and distinguish them from expert concerns.
5. Classify the failure, propose the smallest change, assign an owner, and specify the retest.

A task-based IA audit asks whether people can reach a needed outcome through realistic routes—not whether the sitemap looks tidy.

How do you inspect the complete route rather than menus alone?

Inspect every material component between entry and completion: external landing pages, global and local navigation, hubs, indexes, page groupings, headings, breadcrumbs or other location cues, contextual links, internal search, and the destination itself. At each point, ask what promise the visible wording makes and whether the next page keeps it. Microsoft guidance recommends planning around users' perspectives, common tasks, and mental models, with labels that are accurate, familiar, concise, scannable, and distinguishable.

Check whether people can tell where they are, what level they have reached, what they can do next, and how to recover after an unproductive choice. WCAG 2.2 requires provided headings and labels to describe their topic or purpose. It also addresses the consistent relative order of repeated navigation mechanisms unless the user initiates a change; that requirement does not prohibit local or secondary navigation. Repeat important routes across contexts when device, locale, permission, or journey state changes the available choices.

• Treat a destination with missing or incomplete information as a coverage problem, not automatically a navigation problem.
• Treat a promising label that leads somewhere unexpected as a label or grouping problem.
• Treat an absent next step at the point of need as a cross-link problem.
• Treat search as a valid possible route; its use alone does not prove browse navigation failed.
• Record controls that block an otherwise sound structure as interaction problems.

Which research method should validate an uncertain path?

Choose the method that isolates the uncertainty you need to resolve. Expert inspection and existing behavioural evidence can locate likely defects, but an inspected concern is not an observed user failure. Use card sorting when the question concerns expected groupings or category language: an open sort can reveal how participants name the groups they create. Card sorting does not validate a complete journey through a rendered website, so do not use it as proof that the live navigation works.

Use tree testing when the uncertainty concerns whether hierarchy and labels let people find a destination without page design influencing the result. It can expose confusing categories and divergent paths, but it omits many rendered cues, controls, contextual links, and search behaviours. Use task-based usability testing when the question spans the live interface, alternate routes, recovery, search, or completion. NIST describes this as representative users performing representative tasks, with evidence that may include completion, errors, time, comments, and satisfaction.

• Select completion when the decision concerns whether the intended outcome was reached.
• Record assistance, errors, wrong turns, backtracking, and search reformulations when they explain route friction.
• Ask for destination confidence and participant reasoning when apparent success may conceal ambiguity.
• Interpret divergent paths in context because different routes may both be valid.
• Choose measures for the decision rather than forcing every study into one scorecard.

How do you turn findings into bounded changes or a redesign case?

Turn findings into action by classifying the failure, exposing the prioritisation inputs, choosing the smallest supported intervention, and retesting the affected task. Use a practical taxonomy: coverage, entry, label, grouping, orientation, cross-link, search, consistency, or interaction. This prevents every poor outcome from becoming a proposal to replace the navigation. It also makes ownership clearer: a missing answer, misleading cue, weak search result, and unusable control are different problems even when users describe all four as “hard to find”.

Prioritise with visible inputs such as task importance, affected audiences, observed failure frequency, consequence, evidence strength, and remediation dependencies. Do not hide judgement inside a universal weighted IA score. A redesign case becomes credible when important failures recur across relevant contexts, are supported by observed evidence, are structural rather than local, and cannot reasonably be repaired through bounded changes. Otherwise, correct the content, label, link, grouping, search configuration, consistency issue, or interaction and run the task again.

1. State the failure mode and the evidence supporting it.
2. Show the decision inputs and any material uncertainty.
3. Assign the smallest repair and an accountable owner.
4. Retest the affected tasks, routes, and contexts.
5. Escalate only if repeated structural failures remain after credible bounded options are considered.
6. Engage an experienced information architect or UX researcher when the task set, research design, or trade-offs exceed the team's capability.
7. Use a qualified accessibility specialist for conformance questions; this audit and selected WCAG checks do not establish whole-site conformance.