Observe a task before asking for general opinions.

Fictional example: find a rejected request and explain what information needs correcting. Use the same starting screen and data in each session. Explain that the interface is being tested, not the person.

Avoid naming the button in the task. “Open details” supplies a clue; “Find out why the request was rejected” describes the goal.

Record a concrete observation: the person opened three requests before finding the right one. Separately record your interpretation: perhaps a status filter is missing. Do not treat that hypothesis as a conclusion without checking it.

When someone asks where to click, record the question before helping. Assistance may be necessary to continue, but completing a task with hints is different from completing it independently.

“I dislike this wording” needs a follow-up: what did you understand from it? If the wording leads to a wrong decision, describe that decision. If it is a preference, record it as one.

Group findings into blocked tasks, misunderstandings and optional improvements. For each proposed change, record the observation behind it and how you will check whether it helps.

Suggested record: task; observation; moderator intervention; interpretation; proposed change; owner; follow-up test. Not every comment needs to become a feature.

Repeat the journey after changes and record whether the difficulty remains. A small session offers clues about that task; it does not represent every possible user.