How to write a user research brief

Most user research briefs are written for the calendar invite, not for the study. A PM blocks an hour the day before a stakeholder review, opens a fresh doc, and writes whatever phrasing will get the project approved. Two paragraphs of context the room already knows. A bulleted list of questions the researcher already disagreed with. A timeline that assumes recruitment will work the first time. The brief gets nodded through, the study gets staffed, and three weeks later the team is debating whose interpretation of "what we set out to learn" is the right one.

This is a working guide on how to write a user research brief that holds shape after the meeting: one decision, one research question, the hypotheses worth disconfirming, the participants the study needs to reach, and the synthesis cadence the team will read against. It sits inside the wider voice user research guide and pairs with how to write a user research plan, which is the longer artifact the brief unlocks.

What a user research brief is

A user research brief is a short, written document (a single page at most) that names the decision a study will inform, the research question it will answer, the hypotheses the team holds going in, the participants it needs to reach, the method, the timeline, and the owner. It exists upstream of the research plan. The plan is the playbook the researcher uses to run the study. The brief is the alignment document the team writes before anyone agrees to staff the study at all.

Think of the brief as the artifact that gets the room to commit to a single, falsifiable question before the work starts. If it cannot fit on one page, it is not a brief; it is a kickoff deck wearing the wrong name. If it does not name a decision, it is a topic, not a brief. If the stakeholders sign off and the researcher then writes a different question into the plan, the brief failed at its only job.

Erika Hall's Just Enough Research makes the case, in a different vocabulary, that the most valuable research move a team can make is naming what it does not yet know in writing, before it spends a week trying to find out. The brief is the place that naming happens. Nielsen Norman Group's user research methods overview treats the same step as the one that decides whether the method choice downstream will produce evidence or theatre.

Brief vs plan vs discussion guide

These three artifacts get confused with each other often enough that it is worth holding them apart in one place. They do different jobs, are read by different people, and break differently when collapsed into one document.

The brief vs the plan

The brief is the alignment doc. The plan is the playbook. The brief is read by the stakeholders who need to commit to the study (a PM lead, an engineering manager, a design director, sometimes finance). The plan is read by the person running the study. The brief names the decision. The plan names the method, the prompts, the analysis, the synthesis cadence. The brief is half a page to one page. The plan is two to three. Write them in that order: brief first, plan only after the brief is signed.

Collapsing the two into one document is the most common single failure. The output is a brief that nobody can run from and a plan that nobody can sign off on. The longer treatment of the plan side is in how to write a user research plan; this post sticks to the brief.

The brief vs the discussion guide

The discussion guide is the tactical instrument the interviewer uses in the room: the warmup, the open-ended core, the planned probes for each question, the close. The brief is upstream of all of that. The full pattern for the guide itself is in how to write a discussion guide for user interviews. If the brief and the guide are written by the same person on the same afternoon, the guide is doing the brief's job (justifying the project) instead of its own (running the conversation).

Why most user research briefs fail

Three failure modes show up across teams writing a brief for the first time. They are structural; better writing does not fix them.

The brief is written to defend a study, not to scope it

The most common failure. The PM has already decided the study will happen and writes the brief to get the room to agree. The decision is therefore vague (the team can interpret the result whichever way the meeting goes), the research question is broad (so the study cannot fail to produce something), and the hypotheses are missing (because naming them would constrain the room's reading of the data). The output is a brief that is impossible to disagree with and impossible to learn from.

The fix is to name a decision that could go either way and a research question that admits a disconfirming answer. If the brief cannot be disagreed with on the day it is written, it cannot be learned from on the day the data comes back.

Topics instead of one research question

A second pattern: the brief lists six topics the team wants to learn about and calls them "research questions". "Onboarding", "activation", "pricing", "competitor switching", "feature requests", "team adoption". These are categories. They are not research questions. A team that signs off on a brief like this is signing off on a study that will produce six shallow paragraphs and zero decisions.

The discipline is to pick one, name it as a sentence, and put the rest in a backlog. A single sentence beats six topics every time. The craft of the sentence itself is in how to write user research questions.

No named owner

The third pattern is the brief that lists six stakeholders, four contributors, and no owner. The study runs. Two weeks in, a question comes up about a recruitment tradeoff. The Slack thread loops through everyone on the brief, nobody can answer, the study pauses for a week, and the momentum dies. Briefs without an owner are study death sentences.

Name a single person responsible for every decision the study will produce. They do not have to be the researcher. They do have to be the person the team escalates to.

How to write a user research brief, step by step

Seven steps. The first time it takes 90 minutes. The fifth time it takes 20. The order matters: skipping step 01 (the decision) is what produces every downstream confusion in the synthesis review.

01 · Name the decision the brief unblocks

Before the topic, the question, or the participants: what will the team do differently after this study, depending on what we hear?

If the honest answer is "nothing, this is for context", the study is generative, and that is fine. Write that down explicitly. Generative studies need a different brief shape (broader question, more participants, looser hypotheses) than evaluative ones, and the difference shows up immediately in step 02. If the answer is "we will ship version A if users want it and version B if they don't", the study is evaluative, and the threshold for "want it" goes in the brief, not in the post-hoc synthesis meeting.

The reason this step matters: a brief without a named downstream decision will be reinterpreted in whichever meeting the decision is actually made in. Whoever has the loudest voice in that meeting picks the quote that supports their view, and the research becomes ornamentation rather than input.

02 · Phrase the research question, one sentence

The question is the rudder. One sentence. Specific to a moment, falsifiable, and scoped to a population.

Three rules:

• It names a moment. "Why do users leave?" is too broad. "Why do users who completed onboarding cancel within the first 14 days?" is the right size.
• It admits a disconfirming answer. You should be able to imagine an answer that surprises the team. If every plausible answer leads to the same decision, the question is doing no work.
• It maps to the decision in step 01. If the question can be answered without changing the decision, the question is wrong or the decision is.

03 · Surface assumptions and competing hypotheses

Write down what the team already believes is true. Three to five hypotheses, not more. Each one should be specific enough that the study could disprove it.

Hypotheses serve two purposes. First, they make the team's priors legible to the room, which is the only way the study can ever be allowed to disconfirm them. Second, they give the researcher a list of things to actively listen for in the field. A hypothesis the team forgot to write down is a hypothesis the synthesis will quietly confirm whether the data supports it or not.

A useful pattern: rank the hypotheses by how strongly the room believes them. The brief is the place to surface disagreement, not to paper over it. If two stakeholders hold opposite hypotheses, write both, name who holds each, and let the study resolve the disagreement.

04 · Define participants, segments, and recruitment

Who the study needs to reach. Two layers: the segment (the population the study draws from) and the criteria (what makes a participant qualified within that segment).

The segment is decided by the decision in step 01. A study to inform a churn-intervention decision recruits churners, not active users. A study to inform an onboarding redesign recruits users who joined in the last 30 days, not power users. The wrong segment is the failure mode that wastes more research budget than any other.

Sample size is a function of the method, not of the company's size. Six to twelve per segment for thematic interviews. Five per persona per task for usability. The full breakdown, with the saturation literature behind it, is in how many user interviews do you need. The recruitment plan (sourcing, incentives, scheduling) is in how to recruit user research participants.

05 · Pick the method and the modality

The research question constrains the method. A "why" question wants thematic interviews. A "what happens in the moment" question wants a diary study. A "do users notice this control" question wants a usability test. A "is anything breaking out there right now" question wants a continuous-feedback link placed on the surfaces where users meet the product: the in-product help menu, the pricing page, the cancel flow, the post-onboarding email.

Modality is the second decision. Participants answer in voice when fidelity and honesty matter (the cancel-flow voice answer is the highest-signal feedback most teams will ever collect). Text covers the middle. Choice and rating handle closed-ended moments. The case for letting the participant pick is in voice vs text surveys.

Set probing depth per question, not globally. Shallow on quant-style rating sweeps and in-product feedback where dropout matters. Medium on context-rich discovery questions where the team needs a clarifying probe to act on the answer. Expert on the long-form moments the team would otherwise schedule as a moderated interview, where the AI keeps probing until it has the same context a senior researcher would dig out: contradiction, scope, who, when, how, prior alternatives tried. The participant retains the right to skip on every probe. The longer treatment is in AI follow-up questions for user research.

06 · Set timeline, budget, and ownership

Three numbers: the start date, the readback date, the budget. One name: the owner.

The readback date is the most often-missed line on a brief. Without it, the synthesis slips, the room forgets the brief exists, and the decision in step 01 gets made on the next meeting agenda regardless of whether the study has produced an answer. Put the readback on the calendar at the same time the brief is signed.

The budget covers incentives, tooling, and the researcher's time. A 6-to-12-participant thematic study with light incentives runs $300 to $1,500, depending on the segment. A diary study with three-to-seven entries per participant roughly doubles that. A continuous-feedback program is mostly tooling, not per-study cost. Be honest about the number in the brief; sandbagging the budget is the second most common failure after sandbagging the decision.

The owner is a single name. Not a function, not a team, a person. They are the one the team escalates to when a recruitment tradeoff comes up or a question shifts mid-study.

07 · Circulate the brief inside the team for alignment

Most briefs die in the meeting where they should have come alive: the stakeholder room where the decision actually gets debated. A 30-minute review with five people on calendars is the wrong forum to surface real disagreement on the hypotheses or the question. The PM is presenting; the room is reacting; the silences are taken as agreement.

A better cadence is to share the brief asynchronously inside the company before the meeting and collect a synthesized view of each stakeholder's position on it. Drop a Talkful link into engineering, design, support, finance, and the product trio. Three questions: which hypothesis do you hold strongest, which one would you most want to be wrong about, what would change your mind. Voice or text, the stakeholder's pick, with smart follow-ups when an answer needs one. The brief comes back with a synthesized read of every function's position before the room sits down, and the meeting goes from "convince the room" to "resolve the disagreement we already named". The full pattern for using a study link as an internal-alignment instrument is in how to build a customer feedback loop.

"My strongest hypothesis is that nobody invites a teammate because they don't trust the product enough yet. If the study comes back and shows it's actually that the invite copy reads like marketing, I'd be genuinely surprised. That's the disagreement worth running the study on."

That answer reframes the brief. The room can now run a study on the disagreement between two named hypotheses instead of on a vague "understand onboarding engagement" topic. The brief gets sharper. The room arrives aligned.

When the user research brief is the wrong artifact

Three cases where a brief is the wrong move, and writing one anyway slows the team down.

Pre-PMF, founder-led research. A two-person team running its first ten customer discovery interviews does not need a brief. They need to call the next ten prospects and listen. The playbook for that stage is how to run customer discovery interviews, not a brief-and-plan document chain. Briefs become valuable once the team is large enough that the room running the study is different from the room making the decision.

In-flight continuous-feedback programs. A team running a standing in-product link, a cancel-flow link, and a post-onboarding prompt does not need a fresh brief for every question. The brief was written once for the program, and the per-question work happens against the program brief, not a new one each time. The pattern for that program-level framing is in how to build a customer feedback loop.

One-off tactical questions. A PM who needs to know whether users notice a copy change does not need a brief; they need a five-minute check on the surface. A heavy brief on a small question is research-theatre, and teams learn to ignore briefs entirely when they keep getting written for tasks that did not warrant them.

FAQ

What is a user research brief?

A user research brief is a short written document (a single page at most) that names the decision a study will inform, the research question it will answer, the hypotheses the team holds going in, the participants the study needs to reach, the method, the timeline, and the owner. It sits upstream of the research plan: the brief gets the room to commit to a single falsifiable question before any work is staffed, and the plan is the playbook the researcher writes after the brief is signed.

How long should a user research brief be?

One page, at most. A brief that runs longer has stopped being a brief and become a kickoff deck, a project plan, or a stakeholder briefing in disguise. The discipline of fitting it on a page forces the team to commit to one decision, one research question, and one owner, instead of hedging across six topics nobody can act on. Half a page is usually better than a full page; the briefs that survive contact with the room tend to be shorter than the first draft.

What's the difference between a research brief, a research plan, and a discussion guide?

The brief is the alignment document: read by stakeholders, names the decision, the question, the hypotheses, and the owner. The plan is the playbook: read by the researcher, names the method, the prompts, the analysis, and the synthesis cadence. The discussion guide is the tactical instrument: read by the interviewer in the room, names the warmup, the open-ended core, and the planned probes. The three are written in that order. Collapsing any two into one document is the most common failure mode in product-research operations.

Who should write the user research brief?

The owner of the decision. Most commonly a PM, sometimes a designer, sometimes a founder. The researcher's job is to push back on a weak brief (the topic-list version, the no-decision version, the no-owner version) before the study gets staffed. A brief written by the researcher alone tends to skew toward research-craft and away from the decision; a brief written by the stakeholder alone tends to skew toward justification and away from the question. The best ones are co-written and signed by one person who will own the readback.

How do you get stakeholders aligned on a user research brief?

Share the brief asynchronously before the alignment meeting and collect a synthesized read of each stakeholder's position on it. Three questions: which hypothesis do you hold strongest, which one would you most want to be wrong about, what would change your mind. The room arrives knowing where the real disagreement lives, and the meeting becomes "resolve the named disagreement" instead of "convince the room the study is worth running". This is the internal-feedback use case for a Talkful link inside the company; the wider pattern is in how to build a customer feedback loop.

Do you need a brief for every user research study?

No. A brief earns its weight once the team running the study is different from the team making the decision. Founder-led discovery, in-flight continuous-feedback programs, and one-off tactical checks are usually faster without one. A useful test: would the team meaningfully disagree on what the study is for if the brief did not exist? If yes, write the brief. If no, skip it and go straight to the plan or to the prompt itself.

---

A user research brief is not paperwork, it is the artifact that gets the room to commit to a single, falsifiable question before the study starts. One decision, one research question, named hypotheses, defined participants, a method, an owner, a readback date. Stakeholders signed off on the disagreement worth running the study on, not on a vague topic. Talkful is built for the studies that come downstream of a brief like that: one link participants answer in voice, text, choice, or rating, with adaptive probes that match the depth the question needs, and a synthesis engine that streams themes, quotes, and citations back to the team as the responses land, ready for the trio to act on or for the agents you build with to act on directly. The wider voice user research guide covers where the brief sits in a continuous product-research rhythm.