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. A crowded navigation bar, a high-exit page and complaints about findability are useful signals, but none identifies the cause by itself. The actual defect may be missing content, an unclear label, an unexpected grouping, a weak contextual link, poor search results or an unusable control. Task-level evidence prevents a redesign budget from being committed to the wrong problem.

What decision should the audit be designed to inform?

Design the audit around one bounded decision: whether to repair a section, change labels, prepare a migration or investigate the case for broader restructuring. Information architecture covers organisation, labels and navigation that help people find information, understand where they are and complete intended tasks. The audit therefore examines the route system supporting selected outcomes; it is not automatically a content inventory, technical SEO review, accessibility conformance assessment or redesign exercise.

State which audiences, goals, starting contexts, page types, devices, locales, permissions and journey states are included. Conclusions should apply to those conditions, not to an imaginary average visitor. Record the evidence standard as well: what must be observed before a local concern becomes a finding, and what would justify wider change. This framing keeps an authenticated portal problem from becoming an unsupported claim about the public website.

• Known fact: a verifiable property of the current service or content.
• Behavioural observation: something a participant or dataset actually shows.
• Expert inspection: a concern identified through professional review.
• Hypothesis: a proposed explanation that still needs evidence.

How do you build a representative task set from evidence?

Build the task set from evidence about what people need to achieve, how they attempt it and where problems arise. Write each task as an outcome in language a user would recognise, without revealing the destination label or presumed path. “Find the eligibility conditions before applying” is testable; “Go to Eligibility” gives away the architecture. Define completion as the information, action or confirmed state the participant must reach.

Draw candidates from interviews, observation, previous research, analytics, internal-search queries, support demand, feedback and colleagues who work directly with users. These inputs have different evidential weight. A search query shows words entered, not necessarily the underlying intent; a stakeholder request remains a hypothesis until user evidence supports it. Digital.gov has documented deriving realistic IA test scenarios from earlier research and reviewing their coverage before testing.

• Record the audience, trigger, successful outcome and likely destination.
• Include external entry pages, section pages, authenticated areas and search among plausible starting contexts.
• Balance frequent work with consequential, difficult and underserved tasks.
• Attach the evidence source and note whether it is observed, inferred or asserted.

Review the set as a portfolio rather than ranking tasks by traffic alone. A lower-volume task may carry serious operational consequences, expose a poorly served audience or reveal a route available only under particular permissions. Conversely, a popular page may support several different intentions. The selection rationale should be visible enough for decision-makers to see what the audit represents, which contexts it omits and where further research may be needed.

What should the task-to-route worksheet capture?

The worksheet should connect each evidenced task to its outcome, plausible routes, inspected cues, observed behaviour, diagnosis, proposed owner and retest. Start with realistic entry contexts rather than assuming a home-page visit. Map browse routes, contextual links and internal search, including alternatives that become available only after sign-in or on particular page types. One successful route does not establish that the task works across every relevant context.

At every decision point, record the visible cue, the expectation it creates, the destination reached and whether a person can recognise and recover from a wrong choice. Preserve raw observations separately from interpretation: “returned to the previous page” is an observation; “the category label is ambiguous” is a diagnosis. Using one record from inspection through retesting prevents a recommendation from becoming detached from the evidence that prompted it.

1. Define the task, audience, trigger, outcome and provenance.
2. Trace each plausible route from its actual starting context.
3. Capture cues, choices, destinations, recovery and completion.
4. Classify the failure and state the strength of evidence.
5. Assign the smallest proposed change, an owner and a retest.

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

WCAG 2.2's Multiple Ways success criterion 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. Related links, site maps, search and comprehensive navigation are among the documented techniques. Apply that criterion precisely: it supports inspecting alternate routes, but it neither makes every process step independently locatable nor proves accessibility conformance.

How do you inspect the complete route instead of menus alone?

Inspect every material component between entry and completion: landing pages, global and local navigation, hubs, indexes, page groupings, headings, breadcrumbs or other location cues, contextual links, internal search and the destination itself. A menu can be internally tidy while an external landing page offers no next step. Equally, a sensible hierarchy cannot compensate when the destination lacks the information or action needed to complete the task.

Judge a label by the expectation it creates in context. Microsoft guidance recommends planning navigation around users' perspectives, common tasks and mental models, with labels that are accurate, familiar, concise, scannable and distinguishable. WCAG 2.2's Headings and Labels success criterion separately requires provided headings and labels to describe their topic or purpose. Brevity is therefore not the goal when a short label makes neighbouring choices harder to distinguish.

• Can people tell where they are and what level they have reached?
• Is the next useful action visible at the point of need?
• Does a wrong turn leave a recognisable route back?
• Do repeated navigation mechanisms retain a predictable relative order?
• Do mobile, locale, permission or journey-state changes remove a viable route?

WCAG 2.2's Consistent Navigation success criterion concerns the consistent relative order of navigation mechanisms repeated across a set of pages unless the user initiates a change; it does not ban local or secondary navigation. Test representative page types rather than one template. Treat internal search as a possible preferred route, not automatic evidence of browse failure, and investigate whether its results actually support recognition, confidence and completion.

Which research method should validate each uncertain path?

Choose the method that resolves the specific uncertainty in the decision record. Expert inspection and existing behavioural evidence can identify where to investigate, but an inspected concern is not an observed user failure. Card sorting addresses expected grouping and category language. Tree testing isolates whether hierarchy and labels help people find a destination. Neither method, on its own, validates the complete route through the rendered website.

Use task-based usability testing when the question spans rendered navigation, page cues, controls, contextual links, search, recovery or completion. NIST describes usability testing as representative users performing representative tasks, with possible evidence including completion, errors, time, qualitative comments and satisfaction. Select only measures that inform the audit decision; a universal scorecard can obscure meaningful differences between tasks, audiences and valid alternative routes.

• Grouping or category-language uncertainty: card sorting.
• Hierarchy or label findability without page design: tree testing.
• Rendered-route behaviour and completion: task-based usability testing.
• Likely defects requiring a research focus: expert inspection and existing evidence.

Listen to participants' explanations as well as recording their destinations. Digital.gov's documented IA study analysed both convergent and divergent paths when revising categories and labels. A completed task can still reveal hesitation, an unexpected interpretation or a fragile recovery route; divergence can also be legitimate. Interpret it against the task, starting context and available alternatives instead of treating every different path as an error.

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

Turn each finding into a bounded change by diagnosing the failure before selecting the intervention. Use a consistent taxonomy so that every symptom does not become a navigation recommendation. A missing destination needs different ownership from an ambiguous category; a plausible structure blocked by an unusable control is an interaction problem. Preserve the observation, context and evidence strength beside the classification so reviewers can challenge the reasoning.

• Coverage: required content, action or state is missing or incomplete.
• Entry: a likely starting context offers no plausible route.
• Label or grouping: the cue misleads, or the destination sits somewhere unexpected.
• Orientation or cross-link: location, next step or recovery is unclear.
• Search: relevant queries return missing, misleading or hard-to-interpret results.
• Consistency or interaction: repeated mechanisms change unexpectedly, or the rendered control prevents use.

Prioritise with visible inputs: task importance, affected audiences, observed failure frequency, consequence, evidence strength and remediation dependencies. Do not conceal judgement inside a supposedly universal weighted IA score. Select the smallest supported response, whether that is correcting content, repairing a label or link, regrouping material, tuning search, restructuring a section or commissioning broader change. Assign an owner and define the affected tasks and routes to be retested.

Escalate to redesign only when important failures are repeated across relevant contexts, supported by observed evidence, structural rather than local, and not reasonably repairable through bounded interventions. Retesting closes the decision loop: it shows whether the change improved the task instead of merely making the sitemap look neater. Bring in an experienced information architect or UX researcher when the task set, study design or structural trade-offs exceed the team's capability.

Finish with a retest decision, not a new sitemap by default. If findings raise accessibility questions, involve a qualified accessibility specialist and conduct the appropriate conformance evaluation. The selected WCAG checks in this audit concern particular aspects of multiple ways, descriptive headings and labels, and consistent navigation; reviewing them does not establish whole-site accessibility conformance. The final recommendation should state what is known, what remains uncertain and what evidence would change the decision.