How to Conduct a Task-Based Information Architecture Audit

Audit representative tasks and every plausible route to their outcomes before auditing menus or proposing a new sitemap. A crowded menu, high exits, and complaints about findability are useful leads, but none identifies the failure by itself. The actual defect may be missing content, a misleading label, an unexpected grouping, a weak cross-link, irrelevant search results, or an unusable control. A task-based record keeps the team focused on the journey that must work and the evidence needed to repair it.

What decision should your IA audit inform?

Design the audit around one bounded decision: repair a section, change labels, prepare a migration, or determine whether the evidence supports broader structural change. Information architecture encompasses organization, labels, and navigation that help people find information, understand their location and options, and complete intended tasks. Specify which audiences, goals, starting contexts, page types, devices, locales, permissions, and journey states the audit covers. Its conclusions apply to those contexts, not to an imaginary average visitor.

A task-based IA audit evaluates whether the existing route system supports selected outcomes; it is not a content inventory, technical SEO audit, accessibility conformance evaluation, or redesign exercise. Establish the evidence standard before inspecting the interface. Keep confirmed facts, behavioral observations, expert inspection findings, and untested hypotheses in separate fields so a plausible explanation never acquires the status of observed behavior merely through repetition.

• Decision to be made and the team accountable for making it
• Included audiences, tasks, channels, locales, devices, permissions, and states
• Evidence required for a local repair, section change, migration decision, or redesign case
• Known exclusions and constraints that limit how far conclusions can travel
• Separate labels for facts, observations, inspection findings, and hypotheses

How do you build a representative task set from evidence?

Build the task set by describing outcomes in language users would recognize, without revealing the destination label or presumed navigation answer. 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 each task, record the relevant audience and trigger, realistic starting contexts, the successful content or action, the expected destination when one exists, and the evidence that put the task on the list.

Draw candidates from analytics, internal-search queries, support contacts, feedback, prior studies, interviews, observation, and staff who work directly with users. These inputs can contribute evidence, while non-user opinions remain assumptions. Operational data may locate a question but cannot independently prove intent, cause, or the right structural remedy. Balance frequent tasks with consequential, difficult, and underserved ones; otherwise a high-volume list can conceal journeys whose failure has a larger cost for a smaller audience.

• Outcome stated without exposing the site's current label or hierarchy
• Audience, trigger, and relevant journey state
• External, section-level, authenticated, and search starting contexts
• Successful content, action, or confirmation
• Source evidence and its date, strength, and limitations
• Reason for inclusion: frequency, consequence, difficulty, or underserved need

Review the set for coverage before testing. A documented Digital.gov IA study derived realistic task scenarios from prior research and reviewed them for coverage, illustrating the value of provenance without establishing a universal task count. Look for duplicate scenarios, missing audiences, and tasks that merely restate the current sitemap. Preserve stakeholder proposals as hypotheses until evidence from actual users supports them.

What should a task-to-route worksheet capture?

The worksheet should connect each evidenced task to its successful outcome, plausible routes, inspected cues, observed behavior, diagnosis, proposed owner, and retest. Start with contexts people actually encounter: an external landing page, section page, authenticated area, saved link, or internal search. Map browse, contextual-link, and search routes instead of assuming every journey begins on the home page. At each choice, record the visible cue, the expectation it creates, the destination reached, and the available recovery.

1. Name the task, audience, trigger, outcome, destination, and source evidence.
2. List realistic starting contexts and every material browse, cross-link, and search route.
3. Record cues, choices, destinations, wrong turns, recovery, assistance, and completion.
4. Assign a failure mode, evidence strength, smallest proposed change, owner, and retest.

Alternate routes deserve deliberate inspection. WCAG 2.2's Multiple Ways success criterion requires more than one way to locate a page within a set unless the page is a result of, or a step in, a process. Documented techniques include related links, a site map, search, and comprehensive navigation. Use that criterion with its exception intact, and do not treat reviewing one accessibility requirement as proof of whole-site conformance.

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

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

Inspect the complete route by following each material entry, decision, destination, and recovery point through to the required content or action. A menu can look orderly while the landing page makes the wrong promise, the hub hides the next step, search returns an ambiguous result, or the destination fails to complete the task. Repeat important routes where page type, device, locale, permission, or state materially changes what people can see or do.

• External entry pages and their promises
• Global, local, and authenticated navigation
• Hubs, indexes, page groupings, and headings
• Breadcrumbs and other location cues
• Contextual links at the point of need
• Internal-search queries, results, and reformulations
• Wrong-choice recognition and recovery routes
• Final content, action, confirmation, or next step

Evaluate every label by the expectation it creates. Microsoft guidance recommends planning navigation around user perspectives, common tasks, and mental models, and describes effective labels as accurate, familiar, concise, scannable, and distinguishable. WCAG 2.2's Headings and Labels success criterion requires provided headings and labels to describe their topic or purpose. Short is not automatically clear: compare each cue with nearby choices, the destination it opens, and the language intended users employ.

Check whether people can tell where they are, what level they reached, what they can do next, and how to recover. WCAG 2.2's 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. Internal search can also be a preferred alternate route, so search use alone is not a navigation failure. Examine result relevance, reformulation, confidence, and eventual completion.

Which research method should validate each uncertain path?

Choose the method that answers the unresolved evidence question. Expert inspection and existing behavioral records can identify likely defects, but an inspected concern is not an observed user failure. Use research to test the disputed part of the route rather than selecting a familiar method first and forcing every question into it. The same task scenarios can connect inspection and testing, provided their wording does not reveal the intended path.

• Use card sorting when the uncertainty concerns expected grouping or category language. Digital.gov describes open sorting as a way to learn how participants group content and label the groups they create; it does not validate a complete rendered route.
• Use tree testing when the uncertainty concerns whether hierarchy and labels allow people to find a destination. It isolates that question but omits much of the rendered interface, including many page cues, controls, cross-links, and search behaviors.
• Use task-based usability testing when the question spans the rendered navigation, page cues, controls, contextual links, search, recovery, or completion. NIST describes representative users performing representative tasks and collecting evidence such as completion, errors, time, comments, and satisfaction.
• Use expert inspection to formulate testable concerns, compare route components consistently, and flag obvious mismatches. Keep those findings labeled as inspection evidence until behavior from representative users confirms or challenges them.

Select observations that inform the decision rather than imposing a universal scorecard. Completion, assistance, wrong turns, errors, time, backtracking, search reformulations, destination confidence, and participant reasoning may all be useful. Participants' divergent paths and explanations can expose ambiguous groupings or labels even when some reach the intended destination. Interpret divergence in context because more than one route may be valid, and a successful endpoint can still conceal avoidable uncertainty.

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

Turn findings into action by classifying the failure before choosing the intervention. A failed task does not automatically indicate a navigation problem, and a navigation problem does not automatically justify a new architecture. Tie each finding to the affected task, route, context, observed behavior, and evidence strength. Where the evidence remains indirect or mixed, state the uncertainty and specify what the next test must resolve.

• Coverage: the needed content, action, or state is missing or incomplete.
• Entry: a likely starting context offers no plausible route.
• Label: a cue misdescribes its destination or uses unfamiliar language.
• Grouping: content sits where users do not expect it, or categories overlap.
• Orientation: people cannot identify their location, level, or next step.
• Cross-link: a relevant next route is absent at the point of need.
• Search: relevant queries produce poor, missing, misleading, or unclear results.
• Consistency: repeated navigation changes order, name, or behavior across contexts.
• 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. NIST identifies completion, errors, time, qualitative comments, and satisfaction as possible evidence, but no single measure is mandatory for every decision. Do not hide judgment inside a universal weighted IA score. Select the smallest supported response, whether that is content correction, a label or link repair, regrouping, search tuning, section restructuring, or broader redesign.

Retest the affected tasks and routes before declaring the change successful. Escalate to a broad 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. Bring in an experienced information architect or UX researcher when the task set, research design, or tradeoffs exceed the team's capability. If findings raise accessibility questions, engage a qualified accessibility specialist: this audit and its selected WCAG checks do not establish whole-site conformance.