Task Analysis

Task Analysis

Concept of the skill

Use when auditing a route, defining a route contract, reviewing onboarding or setup flows, diagnosing why a page feels confusing, or when the user asks about top tasks, time-to-value, branching, dead ends, or task complexity.

Coverage

Goal-driven UX analysis for any route or flow: identifying the actor and scenario from persona / journey contracts, extracting the top task for a route, breaking tasks into sequential subtasks with skip paths and blocked states, scoring task friction across five dimensions (discoverability, cognitive load, effort, trust, recovery), identifying breakpoints (dead ends, hidden next steps, excessive branching, unclear success states, misleading value presentation, mobile-only friction, role / permission confusion), and producing the primary / secondary / supporting hierarchy contract for the first viewport that hands off to layout and composition skills. Applies to route audits, onboarding flow reviews, setup wizards, multi-step processes, and any page where "it feels confusing" needs a structured diagnosis. Includes a five-step analysis protocol, a structured output template, an anti-pattern list (Nielsen-first heuristic critique, "rendered correctly" as proof, ignoring skip paths, decorative polish over task completion, fictional persona detail), and a verification checklist that confirms the actor and scenario were named explicitly rather than assumed.

Philosophy of the skill

UX quality is not about how a page looks — it is about whether the page supports the user's top task. Without task analysis, agents default to generic heuristic critique ("add more whitespace," "reduce clutter") that sounds professional but changes nothing about task completion.

This skill exists because aesthetic-first design reviews produce recommendations that do not address why users abandon flows. Task analysis forces the question: what is the user trying to accomplish, and where does the route break that goal? Once the goal is explicit, every layout, copy, and interaction decision can be measured against task support rather than personal taste — and the conversation moves from subjective debate ("I think this looks better") to falsifiable claim ("this change reduces friction at the discoverability dimension for step 2").

Workflow

Use the ordered phases, checklists, and guardrails in the sections below as the canonical workflow for this skill. When multiple subsections describe steps, follow them in the order presented.

If you cannot state the user's goal, top task, and next step, you are not analyzing the UX yet.

When to Activate

Load this skill when:

• auditing a route or flow
• writing or updating route contracts
• checking onboarding / setup / multi-step flows
• diagnosing friction, dead ends, or too many clicks
• deciding what belongs above the fold on a task-heavy page

Core Model

Separate these concepts clearly:

Never confuse a UI interaction with a goal. Filling a form is not the goal; it is a task in service of the goal.

Inputs To Read First

1. The route contract or page contract for the target route (if your team maintains one).
2. The canonical persona definitions for your product.
3. The canonical journey / scenario sequencing for your product.
4. Any narrative route-flow documentation (user-journey docs, sitemaps).

If these inputs are missing, state the missing source of truth instead of inventing task structure. If the inputs exist but disagree (the persona doc says one thing and the journey doc another), flag the discrepancy in your output rather than picking a winner silently.

Caution: these sources may have drifted. Trust the most-recently-updated canonical source for the field in question and document any conflicts you encountered.

Analysis Protocol

1. Identify the actor and scenario

Output:

Actor: <persona_id>
Scenario: <journey_id> — <scenario>
Business objective: <activation | retention | expansion | operational_efficiency>

2. Extract the top task

For the target route, answer:

• What is the primary task this route must support?
• What would success look like in the smallest useful unit of time?
• What information must be visible before the user can proceed confidently?

Also name the hierarchy contract for the first viewport:

• Primary: what must be seen first.
• Secondary: what must frame or support the primary task.
• Supporting: what can wait until the user asks for more detail.

If you cannot name these three layers, you are not ready to decide what belongs above the fold. Once named, hand off to layout-composition to turn the hierarchy into actual section order, scan pattern, and component decisions.

3. Break the task into subtasks

Represent the flow as ordered steps:

Goal
  → Task
    → Subtask 1
    → Subtask 2
    → Branch / skip
    → Completion state

Include skip paths, blocked states, and role-limited variants.

4. Score task friction

For each subtask, evaluate:

5. Identify the breakpoints

Flag the exact point where the journey degrades:

• dead end
• excessive branching
• hidden next step
• unclear success state
• misleading value presentation
• mobile-only friction
• role / permission confusion

Output Template

## Task Analysis

- Actor: <persona>
- Scenario: <journey>
- Top task: <single-sentence task>
- Success metric: <time-to-value or completion target>

### Task Breakdown

1. <subtask>
2. <subtask>
3. <subtask>

### Friction Points

- <point> — why it increases effort or confusion

### Failure Modes

- <documented route failure mode>

### UX Implication

- What must change in layout, copy, affordance, or state handling to support the task better

Anti-Patterns

• Starting with Nielsen heuristics before naming the top task.
• Treating "rendered correctly" as proof the task is supported.
• Ignoring skip paths or role-limited states.
• Counting decorative polish as more important than task completion.
• Using fictional persona detail instead of route / journey evidence.

Evals

This skill ships a comprehension-eval artifact at examples/evals/task-analysis.json. The checklist below is the authoring gate for route and flow analysis; the eval file is the grader surface.

Verification

After applying task analysis, verify:

• Actor and scenario are explicitly named (persona id + journey id), not assumed.
• Top task is stated as a single sentence describing what the user is trying to accomplish.
• Subtasks are listed in sequential order with skip paths and blocked states noted.
• Friction scoring covers all five dimensions (discoverability, cognitive load, effort, trust, recovery).
• Breakpoints identify the exact point where the journey degrades, not generic complaints.
• Primary / secondary / supporting hierarchy contract is named for the first viewport.
• Layout and composition decisions are deferred to layout-composition, not attempted here.
• Recommendations are framed in terms of task support, not aesthetic preference.

Do NOT Use When