Task analysis, knowledge design, and journey mapping

These four methods answer four questions that belong together. Task analysis: what do customers actually do, step by step, including the detours and workarounds that signal friction? Knowledge design: what does the product assume customers know that they do not, and how do we close that gap with content, interface changes, or education? Problem definition: are we solving the right problem, framed in the customer's own words? Journey mapping: how does the whole experience hang together, grounded in observed behavior rather than the ideal path the business imagines?

Why it matters to the business

Inside-out confidence is the enemy. Bain found 80% of companies believed they delivered a superior experience while only 8% of customers agreed. Evidence closes that gap cheaply: Jakob Nielsen's research found testing with just 5 users uncovers about 85% of usability problems. Focus comes cheap too: Gerry McGovern's Top Tasks work shows the top few percent of candidate tasks draw about a quarter of customer votes; those few tasks are where success rates move revenue.

The maps themselves fail without this grounding. Gartner's 2021 survey found 83% of organizations struggle to use journey maps to prioritize CX efforts, while a Nielsen Norman Group survey of over 300 practitioners found 86% relied on customer interviews as the core input to maps that worked.

How to use it

• Inventory candidate tasks from analytics, support logs, and stakeholders; let customers vote to find the top tasks.
• Watch five customers attempt each top task end to end; log detours, workarounds, and time on task.
• Record what each stumble reveals customers did not know; close those gaps with content, interface changes, or education.
• Write the problem statement in the customer's own words before anyone proposes a solution.
• Build the journey map from the observed steps, one actor and one scenario at a time.
• Ship the real output: a prioritized opportunity list with owners and dates.

Where teams get it wrong

The methods fail when run backwards or in isolation: a journey map drafted in a brainstorm, published as truth, then decorated with whatever research agrees with it. A map built from assumptions is a poster of the company's imagination. Run observation first and map second, and treat any journey stage with no supporting evidence as a hypothesis awaiting research, not a fact.

Ask your team

• When did we last watch a real customer attempt our most important task, start to finish?
• What does our product assume customers know that our support tickets prove they do not?
• Is our journey map built from observation, or from a workshop of people who work here?

Evidence first, map second.