Organize help by user task, not by feature module

What it is

Task-, failure-, and outcome-based help architecture builds browse paths from what users want to accomplish, where they are blocked, and which result they need to restore rather than mirroring team or feature-module boundaries. It also maps task and concept IDs to canonical product terms, interface locations, and responsible modules, so user language finds an answer while maintainers can keep guidance accurate as the product changes.

Why it happens

Help seekers usually know a goal or symptom but not its internal ownership. “Reverse a payment” may span orders, payments, and permissions, so module-based fragmentation requires prior product architecture knowledge. A task path connects starting state, conditions, action, and outcome; a failure path connects symptom, state, and recovery. Concept mapping prevents help from inventing vocabulary disconnected from the interface. Together they support novice browsing and direct lookup by practiced users who know the formal term.

Studying it

Build a task, failure, and outcome inventory from observation, support cases, help queries, and failed journeys; sample by frequency, risk, and unresolved cost. Use open card sorting and tree testing to see whether goals and symptoms lead to the right content, then complete the actual task to verify the outcome. Analyze by role, experience, language, and entry rather than treating one sorting consensus as permanent IA. Preserve cross-module ownership for high-value tasks that do not fit one feature.

Where it stops holding

API and operations references may organize by object or feature because looking up a system entity is the task. Mixed audiences can offer task entry, troubleshooting entry, and a reference index. A task title must not erase canonical product terminology or users cannot connect the article back to the interface. The termbase owns concepts, preferred terms, and controlled synonyms; this leaf governs their mapping into help IA. General ranking and correction mechanisms remain search-system design.

Applying it

• Map task ID, user goal, common failure, intended outcome, prerequisites, canonical concepts and terms, interface entry, related articles, content owner, and version.
• Organize primary browsing by high-value task and failure family. Use recognizable goal or symptom titles, then connect to canonical interface terminology at first mention and provide a reference index.
• Assign one content owner to each cross-module journey. On product rename, permission, or flow change, generate an affected-task manifest rather than updating only module pages.
• Audit with tree tests, post-search task completion, and human-escalation reasons. If users find an article but cannot locate its term or result in the product, fix the mapping, document, or product path.

Related

• Same group: T3.02.2 Help entries belong next to where problems occur · T3.02.3 Search must tolerate user vocabulary and synonyms
• Adjacent: T1.04.2 The glossary must cover interface, docs, and support · T3.01.1 Users scan documentation, they don't read it
• Search terms: task-based help IA · failure journey · concept mapping