How to Run 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, high exits and complaints about findability are warning signals, not a diagnosis. The underlying defect may instead be missing content, an unclear label, an absent contextual link, weak search results or a control that people cannot use. Following a consequential task from a realistic starting point keeps the investigation tied to a business decision and prevents an expensive redesign from becoming the default answer.

The practical unit of work is one evidenced task, not one page. For each task, define what successful completion means, record where people may begin, trace browse, contextual-link and search routes, and preserve what was observed at each decision point. That record should travel with the finding through diagnosis, prioritisation, ownership and retesting. It gives website managers, researchers and information architects a common basis for deciding whether a local repair, section restructure or wider migration investment is justified.

What decision should the IA audit inform?

Design the audit around a bounded decision: whether to repair a section, change labels, prepare content for migration or test the case for broader structural change. Then specify the audiences, goals, starting contexts, page types, devices, locales, permissions and journey states that matter to that decision. Conclusions should apply to those contexts, not to an imagined average visitor. This boundary also tells the team which evidence is necessary and which interesting observations can be parked for later.

A task-based IA audit examines whether organisation, labels and navigation help people find information, understand where they are and complete intended tasks. It is not a content inventory, technical SEO audit, accessibility conformance assessment or redesign exercise, although it may expose questions for each discipline. Keep four evidence categories visibly separate: established facts, observed behaviour, findings from expert inspection and hypotheses awaiting validation. A reviewer spotting a vague label is useful evidence of a possible defect, but it is not yet an observed user failure.

• Decision: the approval, repair or investment choice the audit must support.
• Scope: included users, tasks, routes, page types, devices, languages, permissions and states.
• Evidence standard: what observation would confirm, qualify or reject the suspected problem.
• Exclusions: adjacent content, SEO, accessibility or implementation work that needs its own assessment.

How should you build a representative task set?

Build the task set from evidence about what people are trying to achieve, how they attempt it today, where they struggle and what outcome they need. Write each task in language the intended audience would recognise, without naming the presumed section or revealing the navigation answer. A prompt such as finding the eligibility conditions for a service is more useful than directing somebody to an “Eligibility” menu item. Record the audience, trigger, starting contexts, destination, successful outcome and evidence source for every task.

Useful inputs include prior interviews and observation, analytics, internal-search queries, support contacts, feedback, earlier studies and staff who regularly work with users. These inputs do not carry equal weight. A search query shows words entered, while a support ticket records a reported problem; neither alone proves intent, cause or the correct remedy. Mark stakeholder requests and expert assumptions as hypotheses until evidence from users supports them. Digital.gov has documented deriving realistic scenarios from prior research and reviewing their coverage before testing.

• Frequent tasks that account for substantial routine demand.
• Consequential tasks where failure has a serious operational or user cost.
• Difficult tasks already associated with uncertainty, assistance or repeated wrong turns.
• Underserved tasks for audiences, devices, languages or permission states that standard reporting may obscure.

Balance the set rather than selecting only high-volume or easy tasks. Two tasks reaching the same destination may still deserve separate records when their audiences, triggers or entry points differ. Conversely, avoid inflating the list with minor wording variants that test the same route question. The final set should cover the decision sufficiently to make the next investment choice, while retaining provenance so another reviewer can see why each task was included and where an assumption still remains.

What belongs in a task-to-route worksheet?

The worksheet should connect an evidenced task to its successful outcome, realistic starting contexts, plausible routes, inspected cues, observed behaviour, diagnosis, proposed change and retest. Begin with entry points people could genuinely encounter: an external search landing page, a campaign or product page, a section hub, an authenticated portal or internal search. Map browse, contextual-link and search routes without assuming that everyone starts at the home page or that one successful path serves every context.

At each decision point, capture the visible cue, the expectation it creates, the destination reached and the opportunity to recognise and recover from a wrong choice. This sequence distinguishes a misleading label from an unexpected grouping or an absent next-step link. It also preserves a chain from evidence to recommendation when several teams own different parts of the route. WCAG 2.2 Success Criterion 2-4-5 requires more than one way to locate most pages within a set, while retaining exceptions for results and steps in a process.

1. Define the outcome and destination, including what counts as successful completion.
2. List realistic entry, browse, contextual-link and search routes for each relevant context.
3. Record cues, expectations, destinations, wrong turns, recovery and selected observations.
4. Classify the failure, identify the smallest proposed change, assign an owner and specify the retest.

A task-based IA audit does not ask whether the sitemap looks tidy; it asks whether people can reach a needed outcome through realistic routes, with evidence the organisation can act on.

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

Inspect every material component that can advance, misdirect or stop the task: external entry pages, global and local navigation, hubs, page groupings, headings, breadcrumbs, contextual links, internal search, the destination content and the final action. At each step, ask whether the cue makes an accurate promise, whether neighbouring choices are distinguishable, whether the destination fulfils that promise and whether a wrong choice is recoverable. Navigation guidance from Microsoft likewise centres common tasks, user perspectives and mental models rather than organisational structure alone.

Check orientation as well as movement. A person should be able to understand where they are, what level they have reached and what useful options remain. Provided headings and labels must describe their topic or purpose under WCAG 2.2 Success Criterion 2-4-6. Repeated navigation mechanisms must retain the same relative order under Success Criterion 3-2-3 unless the user initiates a change; this does not prohibit local or secondary navigation. Treat these as specific checks, not proof of whole-site accessibility conformance.

• Promise: does the label or link create an accurate expectation of its destination?
• Placement: does the choice appear where the intended audience is likely to look for it?
• Orientation: can people tell where they are and what they can do next?
• Consistency: do repeated mechanisms retain predictable names, order and behaviour?
• Recovery: can somebody recognise an unproductive choice and return to a useful route?
• Completion: does the destination contain the required information, action or state?

Repeat important tasks where page type, device, locale, permission or journey state materially changes the available route. A route that works on a public desktop page may disappear inside a logged-in mobile view. Do not interpret internal search use as automatic evidence of navigation failure: search can be a preferred alternate route. Investigate query reformulation, result relevance, destination confidence and eventual completion before deciding whether the defect belongs to navigation, search, content or the interaction layer.

Which method should validate an uncertain route?

Choose the method that answers the unresolved evidence question. Expert inspection and behavioural data can locate a plausible defect, but they should not be presented as observed user failure. Use card sorting when the uncertainty concerns how people expect content to be grouped or which category language they use. An open sort can reveal participant-created labels, while a closed sort examines placement within predefined categories. Neither validates a complete route through the rendered website.

Use tree testing when the question is whether hierarchy and labels allow people to find a destination without page design influencing their choices. It can reveal confusing categories and divergent paths, but it omits much of the live interface. Use task-based usability testing when the question spans rendered navigation, headings, controls, contextual links, search, recovery or final completion. NIST describes usability testing around representative users undertaking representative tasks, with quantitative and qualitative evidence selected for the study.

• Expert inspection: locate likely route defects and frame hypotheses for validation.
• Card sorting: investigate expected grouping and category language.
• Tree testing: isolate destination findability through hierarchy and labels.
• Rendered-site usability testing: observe complete routes, controls, search, recovery and completion.

Select observations that serve the decision rather than enforcing a universal scorecard. Completion, assistance, errors, wrong turns, time, backtracking, search reformulations, destination confidence and participant reasoning can all be useful. A completed task can still expose ambiguity when participants take sharply divergent paths or cannot explain why the destination seems correct. Interpret such divergence against the task, audience and possibility of valid alternate routes; do not convert it automatically into a hierarchy failure.

How do findings become bounded repairs or a redesign case?

Turn findings into action by classifying the actual failure, exposing the prioritisation inputs and selecting the smallest intervention supported by the record. Do not translate every symptom into “navigation problem”. A missing destination is a coverage failure; an accurate page behind a misleading cue is a label failure; a sound structure blocked by an unusable control is an interaction failure. Clear classification directs ownership and makes the proposed retest specific enough to confirm whether the chosen change worked.

• Coverage: required content, action or state is absent or incomplete.
• Entry: a likely starting context offers no plausible route.
• Label or grouping: the cue misdescribes the destination, or content sits where users do not expect it.
• Orientation or consistency: location, level, next options, names, order or behaviour become unpredictable.
• Cross-link or search: the needed alternate route is absent, irrelevant, misleading or difficult to interpret.
• Interaction: the structure is plausible, but the rendered control prevents effective use.

Prioritise with visible inputs such as task importance, affected audiences, observed failure frequency, consequence, evidence strength and remediation dependencies. Avoid hiding judgement inside a universal weighted IA score. The supported response may be a content correction, label or link repair, regrouping, search tuning or section restructure. Escalate to broad redesign only when important failures are repeated across relevant contexts, observed in evidence, structural rather than local and not reasonably repairable through bounded changes.

Finish with a retest decision, not a new sitemap by default. Run the affected tasks and routes again in the contexts that produced the finding, and define what evidence would show improvement without creating a new failure elsewhere. 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 conduct the appropriate conformance evaluation, because selected navigation checks do not establish whole-site conformance.