Plan UX research around the decisions that are uncertain enough to affect the product scope. Identify the intended users, task, evidence needed and action that follows the finding. Interviews, task observation and prototypes answer different questions; choose methods that can investigate the assumption rather than collecting feedback with no clear decision attached.
Let’s plan your UX research.
Bring your requirements and the decisions you need to make. We’ll help you clarify the scope, explore the trade-offs and plan the next step.
Write a testable learning question
Replace “Do users like the product?” with a specific uncertainty: can the intended role identify the required information, complete an approval or recover after an error? State what is already known and what remains a hypothesis.
Distinguish reported preferences from observed behaviour. A participant's proposed feature may reveal a real need, but it does not prove that their suggested implementation is the best solution.
Create an evidence-capture template
| Field | What to record | Interpretation boundary |
|---|---|---|
| Decision | Product choice the study will inform | Avoid collecting without a purpose |
| Participant context | Relevant role and experience | Do not generalise beyond the sample |
| Task | Goal and starting conditions | Avoid teaching the intended sequence |
| Observation | What happened | Separate fact from explanation |
| Assistance | Prompts or help provided | Distinguish independent completion |
| Interpretation | Possible cause and alternatives | Retain uncertainty |
| Next step | Change, further study or no change | Connect evidence with action |
This is a planning aid, not a fixed research method or a claim that any particular participant count guarantees coverage.
Recruit for the task's variation
Identify differences that may change the experience: responsibility, familiarity, accessibility needs, devices or operating constraints. Select participants with relevant experience rather than only available colleagues.
Use an appropriate consent and information-handling process for the study. Minimise unnecessary personal or commercial information in recordings and notes. Make access and permitted use clear to the people conducting and reviewing the work.
Use a hypothetical approval task
Ask a participant to review a request and determine whether they can authorise it. Observe what they seek, where they hesitate and what they do when information is missing.
If the facilitator supplies an explanation, record it. Completion after coaching is different evidence from an interface that supports the task independently. Ask follow-up questions without rewriting the observed event to match the team's preferred explanation.
Decide what the findings support
A recurring problem can justify a focused design change or another investigation. It does not automatically establish its prevalence in the whole market or its financial impact.
Use other evidence where appropriate: support records, product events, domain review and feasibility work. Contradictory findings are useful signals to investigate rather than reasons to discard inconvenient participants.
Close the decision loop
Record which assumptions changed, what the team will build differently and what remains unresolved. Preserve the link between finding, design decision and later task evaluation.
Do not turn every observation into a feature request. Some findings concern content, training, permissions or the business process rather than additional functionality.
Questions founders ask
Is a small study enough?
It can reveal useful problems within its scope. State the sampling and uncertainty instead of claiming universal coverage.
Should we ask participants which features to build?
Explore their tasks and needs, then evaluate possible interventions. Requested solutions are input, not a complete product specification.
Prepare the study brief
Bring the decision, assumptions and intended participants. Use the prototype decision guide and UI/UX design overview to connect learning with implementation.