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, high exits and complaints about findability are useful starting signals, but none identifies the defect by itself. Trace how someone might arrive from search, a campaign landing page, a section hub, an authenticated area or internal search. Then record the cues, choices, wrong turns, recovery and final outcome. That task-level record lets the team distinguish a missing page from an unclear label, weak cross-link, poor search result or unusable control—and spend redesign or migration money on the problem actually observed.

What decision should the IA audit inform?

The audit should inform one bounded decision: repair a section, change labels, prepare a migration or determine whether a broader redesign case is supported. Information architecture encompasses organization, labels and navigation that help people find information, understand their location and options, and complete intended tasks. That scope is wide enough to include alternate routes and destinations, but focused enough to prevent an audit from becoming a general critique of everything visible on the website.

Write a short decision brief before inspecting the interface. Name the audiences, tasks, starting contexts, page types, devices, locales, permission states and journey stages included. Conclusions should apply to those contexts, not to an imagined average visitor. Also define the evidence required to authorize a local repair, a section-level restructuring or further research. This prevents a redesign preference from quietly becoming the audit's predetermined answer.

• Known facts: confirmed content, system, policy or ownership conditions.
• Observed behaviour: what participants or reliable records show happened.
• Expert findings: concerns identified through structured inspection.
• Hypotheses: explanations or remedies that still require validation.

Keep this work distinct from neighbouring reviews. A content inventory establishes what exists; a technical SEO audit examines search-engine discovery and implementation; an accessibility conformance evaluation assesses applicable requirements; and a redesign creates a new experience. A task-based IA audit diagnoses whether the existing route system supports selected outcomes. It can surface questions for those other disciplines, but it should not claim their conclusions or absorb their entire scope.

How do you build a representative task set from evidence?

Build the task set from evidence about recognizable outcomes, not from the current sitemap. 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 that language without revealing the destination label or presumed route. “Confirm whether my organization qualifies before I apply” produces more diagnostic evidence than “Visit Eligibility,” because the latter supplies the site's answer.

Draw candidates from analytics, internal-search logs, support demand, feedback, previous studies, interviews, observation and staff who work directly with users. These inputs do different jobs. Analytics, exits and search queries can locate questions worth investigating, but they do not independently establish intent, cause or the correct remedy. Stakeholder assertions and expert assumptions belong in the hypothesis column until evidence from actual users supports them.

Balance frequent tasks with consequential, difficult and underserved ones. A documented Digital.gov IA study derived realistic scenarios from prior research and reviewed them for coverage before testing; the useful lesson is the evidence trail, not its case-specific counts. For each selected task, preserve enough provenance for another reviewer to understand why it matters and whether later findings can reasonably inform the audit decision.

• Audience and trigger: who needs the outcome and what starts the need.
• Successful outcome: the information, action or state that completes the task.
• Likely starting contexts: external entry, section page, authenticated area or search.
• Evidence source: research, behaviour, operations or a clearly labelled hypothesis.

What should the task-to-route worksheet capture?

The worksheet should connect each evidenced task to its intended outcome, plausible routes, inspected cues, observed behaviour, diagnosis, proposed owner and retest. Begin with realistic starting contexts rather than assuming everyone arrives at the home page. Map browse paths, contextual links and internal search separately. One path may work from a section hub while the same task stalls for someone arriving on a detailed page from an external search result.

At every decision point, note the cue a person sees, the expectation it creates, the destination reached and whether recovery is possible after an unproductive choice. Preserve observations separately from interpretation: “returned to results and changed the query” is evidence; “the taxonomy is broken” is a hypothesis. Use the same record through inspection, research, prioritization and retesting so a recommendation cannot drift away from the route evidence that prompted it.

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 instead of menus alone?

Inspect every material component from entry to completion: external landing pages, global and local navigation, hubs, page groupings, headings, breadcrumbs or other 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. It also describes effective labels as accurate, familiar, concise, scannable and distinguishable, although clarity still depends on context and intended users.

For each cue, ask what destination it promises and whether the resulting page fulfils that promise. Check whether people can tell where they are, what level they have reached, what they can do next and how they can 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 relative order of repeated navigation mechanisms; it does not prohibit useful local or secondary navigation.

• Repeat important routes across page types, devices, locales, permissions and states when those contexts change available choices.
• Inspect whether contextual links appear at the point of need rather than only in a distant menu.
• Review query wording, result relevance, snippets, filters, reformulation and destination confidence before diagnosing search.
• Treat internal search as a potentially valid alternate route, not automatic proof that navigation failed.

Alternate routes also have an accessibility dimension. The WCAG 2.2 Success Criterion on Multiple Ways requires more than one way to locate a page within a set unless it is a result of, or step in, a process. Related links, a site map, search and comprehensive navigation are documented techniques. Apply the exception accurately, and do not turn this selected check into a claim of whole-site accessibility conformance.

Which research method should validate each uncertain path?

Choose the method that answers the unresolved evidence question. Expert inspection and existing behavioural data can identify likely trouble spots, but an inspected concern is not an observed user failure. Convert it into a testable question: Do people expect this content in another group? Does the hierarchy make the destination findable? Does the rendered control prevent someone from following a structurally plausible route? The uncertainty determines the method.

• Use card sorting to investigate expected groupings and category language. Digital.gov describes open sorts as allowing participants to create and label their own groups.
• Use tree testing to isolate destination findability through hierarchy and labels. It can reveal confusing categories while omitting much of the rendered interface.
• Use task-based usability testing when navigation, headings, controls, contextual links, search, recovery or completion must be evaluated together.
• Use expert inspection to form and refine hypotheses, then label its findings accurately until user evidence confirms them.

NIST describes usability testing as representative users performing representative tasks, with evidence that can include completion, errors, time, qualitative comments and satisfaction. Select only the observations needed for the decision. Assistance, wrong turns, backtracking, query reformulation, destination confidence and participant reasoning may also be useful in an IA study. Divergent paths and explanations can expose ambiguous groupings or labels even when some participants eventually reach the intended destination.

Do not force every study into one universal scorecard. A quick completion can still conceal uncertainty, an accidental choice or a route that fails in another starting context. Conversely, different paths may all be reasonable. Review the route taken, the cues considered and the participant's explanation alongside the outcome. That richer record shows whether the issue lies in grouping, language, entry, recovery or the rendered experience.

How do findings become bounded changes or a justified redesign case?

Turn findings into action by classifying the failure before selecting the fix. A missing destination is a coverage problem; an absent route from a likely starting point is an entry problem; a misleading cue is a label problem. Other useful classes are grouping, orientation, cross-link, search, consistency and interaction. This taxonomy prevents every symptom from becoming a navigation recommendation and keeps ownership close to the system that can correct it.

• Coverage: needed content, action or state is absent or incomplete.
• Entry: an important starting context offers no plausible path.
• Label or grouping: cues misdescribe destinations or categories conflict with expectations.
• Orientation or cross-link: people lose context or cannot see the next relevant route.
• Search or consistency: results fail the need, or repeated mechanisms change unpredictably.
• Interaction: the structure is plausible, but the rendered control prevents use.

Prioritize with visible inputs: task importance, affected audiences, observed failure frequency, consequence, evidence strength and remediation dependencies. Do not bury judgement in a universal weighted IA score. Select the smallest intervention supported by the record, whether that is a content correction, label or link repair, regrouping, search tuning, section restructuring or broader redesign. Assign an owner, define the expected route change and specify the evidence the retest must collect.

Finish with a retest decision, not a new sitemap by default. Escalate 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 changes. Bring in an experienced information architect or UX researcher when the task set, research design or structural trade-offs exceed the team's capability. If findings raise accessibility concerns, involve a qualified accessibility specialist: this audit and its selected WCAG checks do not establish whole-site conformance.