Match a research method to the question and decision while identifying what the method cannot establish.
Choose a research method from the decision awaiting evidence, not from the tool the team usually opens. If the question is 'Where do people get stuck completing this task?', observing the task on a usable version reveals steps, errors and recovery attempts. If it is 'Why did they start the task?', an interview may expose a previous experience and decision context. 'How often did this failure occur among people who started?' requires an event log with a defensible denominator, not a percentage inferred from a few interviews. A statement such as 'I like the design' does not show that a person can complete a task; preference and performance are different outcomes. Methods can be sequenced: observe a failure, ask a neutral follow-up about its possible cause, and then measure after a change. Each result remains limited by the sample, instrument and question.
Build a four-column decision table: research question, observable evidence sought, method and limitation. Interviews have a clear boundary: reported behavior may differ from what someone does in a real task. A small usability test has another: it can expose important problems but need not estimate prevalence across the audience. Event logs have a technical limit: an event is uninterpretable until its definition, capture point and missing records are checked. Write test tasks as believable goals without naming the control whose discoverability you want to assess. If the team wants to understand a person's reasoning, ask 'What did you expect here?' after the action rather than feeding an explanation during it. State how the result will inform a decision: what pattern would prompt a design change, and what finding would keep the hypothesis open?
Lesson summary
Build a four-column decision table: research question, observable evidence sought, method and limitation.
