How to Run a Task-Based Information Architecture Audit

Audit representative user tasks and every plausible route to their outcomes before judging the menu or proposing a new sitemap. A crowded navigation bar, high exits or complaints about findability may point to an unclear label, missing content, weak cross-link, poor search result or unusable control rather than a whole-site structural problem. Define what success looks like, trace where each journey starts, observe where expectations and destinations diverge, and recommend only the smallest change the evidence supports.

What decision must the audit inform?

The audit must be designed around a bounded decision: whether to repair a section, change labels, prepare a migration or test the case for broader structural work. Information architecture encompasses organisation, labels and navigation that help people find information, understand their location and options, and complete intended tasks. The audit therefore examines the route system serving selected outcomes; it does not begin by scoring every page or redrawing the organisation chart as a sitemap.

A task-based IA audit diagnoses whether selected routes support selected tasks; it is distinct from a content inventory, technical SEO audit, accessibility conformance assessment and redesign exercise. Record the included audiences, goals, starting contexts, page types, devices, locales, permissions and journey states. Audit conclusions apply to the audiences, tasks, devices, locales, permissions and journey states actually included, so an observation from a public desktop journey cannot silently become a finding about an authenticated mobile experience.

• Known facts: confirmed content, functionality, ownership and route conditions.
• Observed behaviour: what participants actually did, said or could not complete.
• Expert inspection: a reviewer's evidenced concern about a cue, route or control.
• Hypotheses: stakeholder assertions and possible explanations still requiring validation.

How should you build a representative task set?

Build the task set from evidence about outcomes people need, not from the current menu or departmental structure. 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. Write each scenario in language the intended audience would recognise, without revealing the destination label or suggesting the expected path. A documented Digital.gov IA study derived realistic task scenarios from prior research and reviewed them for coverage before testing.

Analytics, search logs, support data, previous research, interviews, observation and staff who work with users can contribute evidence, while non-user opinions remain assumptions. Analytics, internal-search records, exits and support contacts can locate questions, but they do not independently prove user intent, cause or the correct structural remedy. Record provenance beside each task, including whether it arose from observed behaviour, a recurring service issue, an expert concern or an untested stakeholder belief.

• State the audience and the trigger that creates the need.
• Describe the successful content, action or confirmed end state.
• List realistic starting contexts without assuming a home-page visit.
• Balance frequent tasks with consequential, difficult and underserved tasks.
• Keep the originating evidence and its limitations attached to the scenario.

What belongs in the task-to-route worksheet?

The worksheet must connect each evidenced task to its successful outcome, plausible routes, inspected cues, observed behaviour, diagnosis, proposed owner and retest. A task route may begin on an external landing page, a section page, an authenticated area or internal search rather than the home page. Map browse, contextual-link and search routes separately, because a route that works from one entry context may be invisible from another.

At each decision point, capture the cue a person can see, the expectation it creates, where it leads and whether a wrong choice can be recognised and reversed. WCAG 2.2's Multiple Ways success criterion requires more than one way to locate a page within a set unless that page is a result of, or a step in, a process; documented techniques include related links, a site map, search and comprehensive navigation. Treat that criterion with its exception intact.

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?

Inspect every material route component from entry to completion, including global and local navigation, hubs, page groupings, headings, location cues, contextual links, internal search and the final content or action. Microsoft guidance recommends planning navigation around users' perspectives, common tasks and mental models, and describes effective labels as accurate, familiar, concise, scannable and distinguishable. A short label is not automatically clear; its value lies in the expectation it creates beside nearby choices.

Check whether people can tell where they are, what level they have reached, what they can do next and how to recover. WCAG 2.2's Headings and Labels success criterion requires provided headings and labels to describe their topic or purpose, helping users understand organisation and find information. The Consistent Navigation success criterion addresses the consistent relative order of repeated navigation mechanisms unless the user initiates a change; it does not prohibit local or secondary navigation.

• Open the likely external landing pages and check whether their promises match their destinations.
• Walk global navigation, section navigation, hubs and indexes without assuming one preferred hierarchy.
• Compare labels with nearby alternatives and with the headings or actions on the destination.
• Check breadcrumbs or other location cues for useful orientation and recovery.
• Inspect contextual links where a related task or next step becomes relevant.
• Try realistic internal-search terms, refinements, results and destination pages.
• Repeat material journeys across devices, locales, permissions and states that change available routes.

Internal search can be a valid preferred route and its use alone does not establish that navigation has failed. Investigate whether people reformulate queries, recognise relevant results, trust the destination and complete the task. Similarly, an exit may reflect successful completion, a deliberate change of channel or a broken route. Combine the signal with the page context and observed reasoning before assigning a failure mode.

Which method should validate an uncertain path?

Choose the method that answers the unresolved evidence question. Expert inspection and existing behavioural evidence can locate a likely defect, but an inspected concern is not an observed user failure. Card sorting, tree testing and rendered-site usability testing answer different evidence questions and should not be treated as interchangeable. Start with the uncertainty, then select the lightest method capable of resolving it with evidence strong enough for the pending decision.

• Use expert inspection to identify suspected route, cue, consistency or recovery problems that need confirmation.
• Use card sorting when the question concerns expected groupings or category language. Digital.gov describes card sorting as a method for learning how participants group content and, in open sorts, how they label the groups they create.
• Use tree testing when the question concerns destination findability through a hierarchy. Tree testing can reveal confusing categories or labels, but it omits much of the rendered interface.
• Use task-based usability testing when rendered navigation, page cues, controls, contextual links, search, recovery or completion affect the question.

NIST describes usability testing as representative users performing representative tasks, with evidence that can include completion, errors, time, qualitative comments and satisfaction. Select only measures that inform the audit decision; assistance, wrong turns, backtracking, search reformulations, destination confidence and participant reasoning may be more revealing than a single completion result. Participants' divergent paths and explanations can expose ambiguous groupings or labels even when some people reach the intended destination.

How do findings become bounded changes or a redesign case?

Turn each finding into a bounded recommendation by classifying the actual defect before selecting the remedy. Classifying findings as coverage, entry, label, grouping, orientation, cross-link, search, consistency or interaction failures helps keep the proposed remedy tied to the observed defect. It also prevents a missing page, misleading heading or unusable menu control from being reported as proof that the entire hierarchy must change.

• Coverage: the required content, action or state is absent or incomplete.
• Entry: a likely starting context offers no plausible route.
• Label: a cue makes the wrong promise or uses unfamiliar language.
• Grouping: categories overlap or place the destination where people do not expect it.
• Orientation: people cannot locate themselves or identify the next useful step.
• Cross-link: a relevant next route is missing at the point of need.
• Search: queries return missing, misleading or difficult-to-interpret results.
• Consistency: repeated navigation changes name, order or behaviour unexpectedly.
• Interaction: the structure is plausible, but the rendered control prevents use.

Prioritisation should expose task importance, affected audiences, observed failure, consequence, evidence strength and remediation dependencies rather than hide judgement in a universal composite score. NIST identifies completion, errors, time, qualitative comments and satisfaction as possible forms of usability evidence, not a mandatory scorecard. Record which inputs drove the decision so an owner can distinguish an urgent, well-observed breakdown from a plausible concern that still needs validation.

The audit should recommend the smallest change supported by the evidence and retest the affected tasks and routes before declaring success. That may mean correcting content, repairing a label or link, regrouping a section, tuning search, restructuring part of the site or, where the record warrants it, redesigning more broadly. A broad redesign case is justified only when important task failures are repeated across relevant contexts, supported by observed evidence, structural rather than local, and unlikely to be repaired through bounded changes.

Finish with a retest decision and a named owner, not a fresh sitemap by default. Bring in an experienced information architect or UX researcher when the task set, study design or structural trade-offs exceed the team's capability. If findings raise accessibility questions, involve a qualified accessibility specialist and run the appropriate conformance evaluation. A task-based IA audit and its selected WCAG checks do not establish whole-site accessibility conformance.