How to Conduct a Task-Based Information Architecture Audit

Audit representative user tasks and every plausible route to their outcomes before judging menus or drawing a new sitemap. A crowded navigation bar, a high-exit page or a complaint about findability can identify somewhere to investigate, but none establishes the cause. Trace how a person could arrive, browse, follow a contextual link, search, recover from a wrong turn and complete the task. That record shows whether the defect lies in coverage, entry, labels, grouping, orientation, cross-links, search, consistency or interaction.

The practical aim is not to make the architecture look tidy. It is to give decision-makers evidence for a bounded repair, migration choice or redesign case. Keep the task, route, observed behaviour, diagnosis and proposed retest connected throughout the audit. Otherwise, a local content or link problem can be mistaken for a whole-site structural failure, consuming redesign effort without improving the journey that prompted the work.

What decision should your IA audit inform?

Design the audit around one explicit decision, such as repairing a section, changing labels, preparing a migration or deciding whether broader restructuring is justified. Information architecture encompasses organisation, labels and navigation that help people find information, understand their location and options, and complete intended tasks. Define the audiences, goals, entry contexts, page types, devices, locales, permissions and journey states that matter to the decision, then limit conclusions to those contexts.

A task-based IA audit diagnoses whether the existing route system supports selected tasks. It is not a substitute for a content inventory, technical SEO audit, accessibility conformance evaluation or redesign process, although findings may prompt those activities. Establish the evidence standard before inspecting the interface. Keep known facts, behavioural observations, expert findings and untested assumptions visibly separate so stakeholders can see which recommendations rest on observed behaviour and which still require validation.

• Decision: the approval, repair or investment choice the audit must support
• Scope: included audiences, routes, devices, locales, permissions and states
• Evidence: what is known, observed, inspected or still hypothesised
• Boundary: what another specialist audit or workstream must determine

How do you build a representative task set from evidence?

Build the task set from evidence about what people need to achieve, not from the current menu. Write each task as a recognisable outcome without revealing the destination label or preferred route. GOV.UK guidance recommends learning what people are trying to do, how they currently do it, the problems they experience and the outcome they need. For every task, record its audience, trigger, likely starting contexts, successful outcome, destination and evidence provenance.

Analytics, internal-search logs, support data, earlier research, interviews, observation and staff who work directly with users can all contribute evidence; non-user opinions remain assumptions. Operational data can show where to investigate but cannot independently prove intent, cause or the right structural remedy. A documented Digital.gov study derived realistic task scenarios from previous research and reviewed their coverage before testing. Apply that principle without copying the study's project-specific participant or task counts.

• Include frequent tasks that shape routine use.
• Include consequential tasks where failure carries meaningful business or user impact.
• Include difficult tasks already associated with confusion, assistance or repeated searching.
• Include underserved audiences and contexts that aggregate data may conceal.

What should your task-to-route worksheet capture?

Use one worksheet to connect each evidenced task with its intended outcome, plausible routes, inspected cues, observations, diagnosis, owner and retest. Begin with realistic starting contexts: an external landing page, a section page, an authenticated area, a contextual link or internal search. Do not assume every journey starts on the home page. Map material browse, cross-link and search routes, including alternatives that may suit different audiences, devices, permissions or journey states.

At every decision point, record the visible cue, the expectation it creates, the destination reached and whether a person can recognise and recover from an unproductive choice. The WCAG 2.2 success criterion on multiple ways requires more than one way to locate a page within a set, except where the page is a result of or step in a process; documented techniques include related links, a site map, search and comprehensive navigation. Search can therefore be a valid alternate route, not proof of navigation failure.

A task-based IA audit asks whether people can reach a needed outcome through realistic routes, with evidence the organisation can act on.

WebChorus Editorial Team

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

Inspect the complete route from entry to successful content or action, including global and local navigation, hubs, page groupings, headings, location cues, contextual links, search results and the destination itself. Microsoft guidance recommends planning navigation around users' perspectives, common tasks and mental models. It describes useful labels as accurate, familiar, concise, scannable and distinguishable. Judge each cue by the expectation it creates in context, not by brevity alone.

Check whether people can tell where they are, what level they have reached, what they can do next and how to recover. The WCAG 2.2 success criterion on headings and labels requires provided headings and labels to describe their topic or purpose. The success criterion on consistent navigation addresses the consistent relative order of repeated navigation mechanisms unless a user initiates a change; it does not prohibit local or secondary navigation. These are focused checks, not a complete accessibility evaluation.

• Entry: does the likely starting page offer a plausible next step?
• Promise: does each label accurately foreshadow its destination?
• Placement: does the grouping fit the task and intended audience?
• Orientation: can the person identify location, level and available options?
• Recovery: can a wrong choice be recognised and reversed?
• Cross-link: is the next route available at the point of need?
• Search: are relevant results understandable and useful for completion?
• Destination: does the final page contain the required information, action or state?

Which research method should validate each uncertain path?

Choose the method that answers the unresolved evidence question. Expert inspection and existing behavioural evidence can locate likely defects, but an inspected concern is not an observed user failure. Digital.gov describes card sorting as a way to learn how participants group content and, in open sorts, how they label the groups they create. Use it for uncertainty about expected groupings or category language, not to validate a complete route through the rendered website.

Use tree testing when the question is whether hierarchy and labels enable people to find a destination without page design influencing the result. It can expose confusing categories and divergent paths, but omits much of the rendered interface. For navigation controls, page cues, contextual links, search behaviour, recovery and completion, use task-based usability testing. NIST describes usability testing as representative users performing representative tasks, with evidence including completion, errors, time, qualitative comments and satisfaction.

• Expert inspection: identify a likely defect and state it as a hypothesis for validation.
• Card sorting: investigate expected content groupings and the language people use for categories.
• Tree testing: isolate findability through a hierarchy and examine category or label confusion.
• Rendered-site usability testing: observe complete routes, controls, cross-links, search, recovery and task completion.
• Selected measures: capture only what informs the decision, such as completion, assistance, wrong turns, time, backtracking, query reformulation, destination confidence and participant reasoning.

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

Classify the failure before selecting the intervention, then recommend the smallest change supported by the record. A missing destination is a coverage problem, an unavailable route from a likely starting point is an entry problem, and an unclear cue is a label problem. Keep grouping, orientation, cross-link, search, consistency and interaction failures distinct as well. This prevents every symptom from becoming a navigation recommendation or an argument for wholesale redesign.

Prioritise with visible inputs: task importance, affected audiences, observed failure frequency, consequence, evidence strength and remediation dependencies. Do not bury judgement inside a universal weighted score. NIST identifies completion, errors, time, qualitative comments and satisfaction as possible evidence from representative task testing, but those measures are not a mandatory scorecard. Select the observations that resolve the audit decision and preserve their context in the worksheet.

• Coverage: correct or create the required content, action or state.
• Entry: add a plausible route from the affected starting context.
• Label: revise the cue and test whether its promise is understood.
• Grouping: regroup destinations whose placement or overlap causes confusion.
• Orientation: improve location and next-step cues.
• Cross-link: add the missing route at the point of need.
• Search: tune retrieval, result presentation or query handling.
• Consistency: align repeated names, order or behaviour where appropriate.
• Interaction: repair the rendered control or page design that prevents use.

Retest the affected tasks and routes before declaring success. Escalate to broad structural change only when important failures recur across relevant contexts, are supported by observed evidence, are structural rather than local, and cannot reasonably be repaired through bounded content, label, link, grouping or search changes. Bring in an experienced information architect or UX researcher when the task set, research design or trade-offs exceed the team's capability. If accessibility questions emerge, engage an accessibility specialist: these selected WCAG checks do not establish whole-site conformance.