A user research plan connects a product decision to the evidence needed to make it. It does not need to predict every answer. It needs to say what the team wants to learn, who can provide useful perspective, how the sessions will run, and how the findings will change a decision. Keep the plan visible so research partners can challenge the assumptions before recruitment begins.
Use the Boardmix user interview template as a starting point, then add the decision, participant criteria and evidence path around it. A shared canvas helps researchers and product partners see the same scope without turning the plan into a private document.

Start with the decision the research should inform
Write the product decision before writing a recruitment brief. For example: “Should we simplify the first project setup, or improve guidance for returning users?” The question names a choice. “Learn what users think of setup” is a useful intention but not a decision boundary.
Record the decision owner, the review point and what is already known. Separate evidence from belief: a support theme, an analytics observation and a stakeholder preference are not interchangeable. Add a “not researching” area for questions that may be valuable later but would expand the current study.
| Field | Example |
|---|---|
| Decision | Choose the first improvement for project setup. |
| Decision owner | Product manager for new workspaces |
| Known signal | New users ask where to find their first board. |
| Open question | Is the main problem navigation, terminology or missing guidance? |
| Review point | Product review after the sessions and synthesis. |
Write questions that can be answered
Turn the decision into a small set of research questions. Ask about a recent behavior, the context around it and the outcome the person wanted. “Tell us about the last time you created a board” invites an account of an event. “Would you use a setup checklist?” asks for a prediction and is weaker evidence for a behavior decision.
Mark each question as primary, supporting or out of scope. Primary questions must connect to the decision; supporting questions help explain the answer. Keep leading language out of the script. If the team hopes that a new feature is useful, ask how participants solve the problem today before showing a concept.
Define what would count as useful evidence without pre-deciding the result. It may be a repeated workflow, a concrete obstacle, or a difference between two user contexts. Do not promise a statistically representative result from a small qualitative study; describe the evidence the method can actually provide.
Choose participants and a method
Describe participants by the behavior or situation relevant to the decision, not only by a broad demographic label. A study about first project setup may need people who recently created a workspace, while a study about team permissions may need someone who invites collaborators. Note exclusions that would make the session unsafe or irrelevant.
Choose the method that matches the question. A contextual interview is useful for understanding a workflow; a concept discussion can reveal language and expectations; a short diary can show how a task unfolds over time. If you combine methods, say which question each one answers. The plan should also name the moderator, note-taker and recording consent process.

Plan how evidence will be captured
Prepare one place for observations, participant language, interpretation and follow-up questions. Keep these categories separate. A note such as “the participant searched the top navigation twice” is an observation; “navigation is confusing” is an interpretation. Both matter, but they should not be mixed in the raw record.
Add a field for source and context. A quote without the task, situation or timestamp can be misused later. Use short labels to connect notes to a research question, and record contradictory evidence instead of removing it. If a session is incomplete, mark the gap so the team knows not to treat it as a clear finding.
Set expectations for accessibility, privacy and storage before sessions start. Only collect information needed for the research decision, and use the team’s approved handling process for recordings or sensitive details. A shared board is useful for synthesis, but its sharing scope must match the sensitivity of the material.
Set an analysis path before sessions begin
Decide how the team will move from notes to findings. You might first cluster observations by task, then label patterns, contradictions and unanswered questions. Define a finding as a statement supported by multiple pieces of evidence or a clearly important outlier that changes the decision. Do not turn every interesting quote into a finding.
| Stage | Working question |
|---|---|
| Capture | What did the person do, say or show? |
| Group | Which notes describe the same task or obstacle? |
| Challenge | What contradicts this pattern, and what context explains it? |
| Decide | Which product choice does the evidence support or question? |
Share findings as decisions and next steps
End the plan with the format of the readout: a short finding, the evidence behind it, the implication for the decision and the next action. Include unresolved questions and limits of the study in the relevant section, not as a generic disclaimer that hides the useful answer.
Invite the decision owner to review the synthesis with the researchers. Keep the original notes accessible, but give the final readout a clear status so future readers know what was decided and what remains an assumption. The Boardmix user guide covers the ordinary canvas tools used to group and annotate research material.
When your scope is clear, open a Boardmix workspace and turn the plan into a shared working board. A concise question, an appropriate method and an explicit evidence path make the study easier to run and easier to use.