Observe a prototype task attempt without coaching the route

A design discussion can reveal useful opinions without showing what someone does when trying to finish a task. Observing an attempt provides a different kind of evidence: actions, recovery, and assistance in sequence. Use an invented prototype and a consenting participant. Keep manual notes rather than assuming the meeting space records the session.

Give the outcome without the route

For this fictional practice exercise, imagine a clickable approval prototype with a draft page and a review page. Its two similarly labeled actions are Request review and Review request. The participant's task is to return a draft to its author for correction before final approval. State that outcome without telling them which screen or control to choose.

Check that the invented prototype can represent the intended action. If it cannot, document the limitation before treating a dead end as a participant mistake. Explain that the design is under review, not the person's ability. Agree that they can stop or ask to pause.

Log actions before explanations

An invented attempt record might say: opened the draft; selected Request review; inspected the resulting page; returned to the draft; opened Review request; looked for a return action. These are illustrative notes, not a performed user study or a measured product result. Attach observed screen names and actions to their order.

Record a pause as a pause, not as confusion unless the participant says so. Note any request for help and the exact prompt you give. Avoid finishing a sentence for them or pointing to the intended action. Such help may be appropriate, but it changes what the subsequent completion demonstrates.

Mark assistance and recovery explicitly

Suppose the invented observer asks the participant to check the review page. That is a directional prompt, even if no button is named. Mark the point in the record and label later completion as assisted. In the imagined assisted continuation, they open the review page, select Return for correction, and see the draft marked Changes requested. Record that finish without removing the prompt from the summary.

Keep recovery paths visible too. Returning to the earlier page can be deliberate exploration, correction of a mistaken choice, or something else. The action alone does not establish its reason. If the prototype breaks or the task is impossible, end the attempt and record that limit rather than repeatedly coaching someone toward a fictional successful finish.

Ask about a specific step afterward

After the attempt, ask what the participant expected when choosing Request review. Refer to the observed action instead of asking a leading question such as were those labels confusing. Write the person's explanation separately from the observer's interpretation. A retrospective account can clarify intent, but it should not overwrite the chronological actions.

For the fictional example, the person might say they expected both labels to open the same page. That supports investigating the labels and destination cues for this attempt. It does not establish how all visitors interpret them or prove that changing one word will solve the task.

Choose a bounded follow-up question

Keep the task, starting state, ordered actions, prompts, outcome, and later explanation together. Decide what to investigate next: can clearer action labels help an unfamiliar participant distinguish starting a review from inspecting an existing request? A follow-up can use a revised prototype, while preserving the same intended task and noting any changed conditions.

If several attempts are available, compare similar starting conditions and retain differences rather than collapsing them into a universal finding. One fictional attempt supplies no success rate or customer outcome. The useful finish is a traceable task record and a concrete prototype question, with independent completion, assisted completion, and incomplete attempts clearly distinguished.