Task analysis: watch what customers do, not what they say

Task analysis is the practice of watching customers do real tasks, step by step, in real conditions. It works in two layers: the WHAT, meaning the actions you observe, and the HOW, meaning the tools people use, the knowledge they need, and the workarounds they invent. Its most valuable output is the knowledge gap: the distance between what your team assumes customers know and what they actually know. A customer types 'navy blue' into a field expecting a Pantone code. She understands color perfectly. She does not know your system. The product assumed knowledge she never had.

Why it matters to the business

You cannot find knowledge gaps in a survey, because surveys capture what people say, and people are unreliable narrators of their own behavior. A sampling study by the analytics firm 84.51 found that 75% of respondents misstated their own purchase behavior when checked against loyalty-card data. Meanwhile the bill for unfound gaps arrives as support tickets, abandoned carts, and quiet churn. The good news is that observation is cheap: Jakob Nielsen's research at Nielsen Norman Group found that testing with just five users uncovers roughly 85% of usability problems. A week of watching real customers usually beats a quarter of survey analysis.

How to use it

• Pick your three highest-volume or highest-revenue customer tasks and observe five real customers completing each one.
• Log every stall, error, workaround, and abandonment. These are gap markers, not user mistakes.
• For each failure, name the specific knowledge the product assumed: a term, a code, a sequence, a convention.
• Fix gaps in the design itself, through labels, defaults, and examples, not in an FAQ nobody reads.
• Retest with five fresh users after each fix. Three small rounds beat one big study.

Where teams get it wrong

Teams substitute surveys and analytics for observation, then blame users when tasks fail. Analytics shows where people drop off; only observation shows why. And when a gap is found, the reflex is to write documentation or train the customer. That treats a design failure as a user failure, and the tickets keep coming.

Ask your team

• When did someone on this team last watch a real customer complete our most important task, start to finish?
• What do our top three support-ticket categories tell us customers don't know?
• Which steps in our core flow assume vocabulary or knowledge only insiders have?

Knowledge gaps are design failures, not user failures.