AIWorkDex
Customer Research Practice

Run a lightweight observed task session

Observe a realistic task, identify concrete failures, and choose a change to test next.

Preparation
Preparation, sessions, and a review round
Difficulty
Moderate
Task
Observe a realistic user task
Back to the Task: Observe a realistic user task

Before you start

Get what you need before you start

  • Choose a prototype that can answer the research question.
  • Confirm consent, recording, accessibility, and data-handling arrangements.

Steps

Work through the method

Use the listed inputs and tools. Check the evidence when you need to verify a step.

  1. Define the realistic task

    Write a scenario with a goal, starting state, and observable completion condition.

    Why it matters: The task needs a clear relationship to the research question.

    Input
    The key user job and prototype state.
    Output
    A task scenario and completion condition.
    Tools in this stepGoogle Sheets

    Evidence for this step

  2. Recruit likely users

    Screen for people who would plausibly attempt this task in the relevant context.

    Why it matters: Selection affects what the team can infer from the session.

    Input
    The task scenario and participant criteria.
    Output
    Consented participants with relevant experience.
    Tools in this stepGoogle Sheets

    Evidence for this step

  3. Prepare the prototype and fallback

    Set the prototype to the required starting state and prepare a safe response for broken paths.

    Why it matters: A predictable setup keeps prototype failures distinct from facilitation problems.

    Input
    The prototype and task scenario.
    Output
    A tested session setup.
    Tools in this stepGoogle Sheets

    Evidence for this step

  4. Observe without coaching

    Give the task, let the participant act, and record any facilitator intervention separately.

    Why it matters: Coaching can change the behaviour under study.

    Input
    The participant, task, and prototype.
    Output
    A chronological observation record.
    Tools in this stepGoogle Sheets

    Evidence for this step

  5. Ask after the attempt

    Ask what the participant expected at hesitation, error, abandonment, and completion points.

    Why it matters: The follow-up connects observed behaviour with the participant’s account.

    Input
    The observation record.
    Output
    Source-linked comments for key moments.
    Tools in this stepGoogle Sheets

    Evidence for this step

  6. Group common errors carefully

    Group similar observed failures and retain the participant codes and contrary cases.

    Why it matters: A repeated pattern must remain traceable to individual sessions.

    Input
    De-identified observation records.
    Output
    An evidence-linked problem list.
    Tools in this stepGoogle Sheets

    Evidence for this step

  7. Choose a change to retest

    Select one change tied to a supported problem and define the same task for the next round.

    Why it matters: The session should end with an inspectable change and another test.

    Input
    The problem list and prototype constraints.
    Output
    A change hypothesis and retest task.
    Tools in this stepGoogle Sheets

    Evidence for this step

Success checks

Check the result before you finish

  • The task has an observable completion condition.
  • Facilitator interventions remain visible in the record.
  • Each proposed change links to observed behaviour.

Failure modes

Watch for these problems

  • Revise the task when participants fail because the scenario lacks required context.
  • Report accessibility or prototype failures separately from product findings.
  • Recruit a different group when selection limits block the intended inference.

Tools

Choose the tools you need

Sources

Read the sources behind this practice

Check what each source supports and where the advice has limits.