How to Write a One-Page Research Decision Brief

“Can we run a survey about customer support?” sounds like a brief until you try to use it. You could investigate response times, opening hours, returns, or whether people like the help centre. Each would produce answers. The person approving the study might still be waiting to hear whether they should hire someone for evenings.

Before you write your survey, write a one-page decision brief that names the choice you face and the evidence that could change it.

I think this is the most useful place to cut a small study down. Once I've started drafting questions, every extra question can seem cheap. Another minute of someone's time, another thing we might learn. The brief makes me ask whether that extra answer would help anyone make the decision.

What is a research decision brief?

A research decision brief is a short planning document connecting a decision to the uncertainty blocking it, the people who can help resolve it, and the evidence you need. It also records what you already know and what you will do with different findings.

It comes before the questionnaire or discussion guide. Someone reading it should be able to explain why the study exists without seeing a single participant question.

UXR Chile's research-plan template, dated September 21, 2026, describes a one-page plan connecting what will be learned, the method, and the decision. Its opening section covers the problem or context and what is already known. It recommends no more than three research questions, treating a fourth as a sign that scope is expanding.

That maximum is a template convention, not a scientific rule. For the small-study workflow here, I recommend one primary research question. That's my adaptation, along with the six fields below. You can have supporting questions, but they should help answer the primary one rather than open separate investigations.

One page is a useful constraint, not a formatting test. If you need tiny type to fit everything, you probably have more decisions than you've admitted.

Why write a brief before a survey?

A broad request leaves each person free to imagine a different purpose. A founder wants a staffing decision. The support lead wants to understand unresolved problems. Marketing wants a satisfaction number for a presentation. Everyone approves “customer support research,” then disagrees about whether the results are useful.

Writing the decision down exposes that disagreement while changing the study is still cheap.

It also creates a boundary around the evidence. Customers can describe what happened when they needed help. Their accounts alone cannot establish whether an evening shift will pay for itself. That decision may also need contact volumes, staffing costs, and a test of the proposed hours.

I want those limits written down before a vivid customer quote arrives. Otherwise, it's easy to promote the quote into proof of whatever I already wanted to do.

How does a decision brief work?

Think of it as a shopping list written after you've decided what to cook. Without the meal in mind, you can come home with good ingredients that don't quite make dinner. A research study can do the same thing with perfectly reasonable answers.

The mechanism is straightforward. Start with the available choices. Name the uncertainty that prevents you from choosing. Then work backwards to the evidence that could reduce that uncertainty and the people whose experiences are relevant.

Before collecting anything, write down what different plausible findings would make you do. This won't remove judgment. It makes that judgment visible, so you can notice when your interpretation changes after seeing the results.

If you cannot describe a finding that would alter your next step, pause. Maybe the decision is already made. Maybe the work is intended to document a baseline or improve an implementation. Those can be valid purposes, but they need a different brief.

A six-field decision brief template

Copy these fields into a shared document. Ask the person who owns the decision to review it before anyone starts recruiting.

1. Decision to make

Fill in: “By [date], [decision owner] needs to choose between [available actions] because [problem or context]. We already know [existing evidence].”

Name an action that someone has authority to take. “Understand our customers better” gives you no stopping point. “Decide whether to test evening support” does.

Keep the context short. Include what existing records or earlier work tell you, and distinguish those observations from assumptions. This stops the team paying to rediscover something it already knows.

2. Uncertainty blocking it

Fill in: “We cannot choose yet because we do not know [specific uncertainty]. Our primary research question is [one answerable question].”

The primary question belongs to the study plan. It doesn't have to be a sentence you will ask participants verbatim.

Keep it close to something people can know from experience. Customers can explain a recent attempt to get help and what happened afterwards. They cannot reliably tell you the commercial return on a staffing change.

3. Relevant people

Fill in: “We need evidence from [people with a relevant experience] during [time period]. We also need to consider [a useful comparison or people our recruitment might miss].”

Define relevance through experience, rather than defaulting to “our customers.” A person who bought once and never needed support may have little to contribute to a study about unavailable help.

Also name the reach of your sample. Recruiting only through support tickets misses customers who saw the opening hours and never submitted one. Recruiting only people who had a problem cannot tell you how common that problem is across the whole customer base.

4. Evidence needed

Fill in: “To inform this choice, we need [accounts, observations, or measures]. We will collect them through [method or source] and read them alongside [existing evidence]. This will not establish [limit].”

Describe what would count as evidence, rather than listing topics. “Support preferences” is a topic. Recent accounts of when help was needed, whether waiting was possible, and what the delay prevented are evidence you can examine.

Record the intended collection method briefly here. You don't need a tool comparison. You do need to know whether the proposed study can produce the evidence you've named.

5. What different findings would change

Fill in: “If we find [plausible pattern], we will consider [action]. If we find [different pattern], we will consider [different action]. If the evidence is mixed or insufficient, we will [next step].”

Avoid inventing a percentage threshold just to make the plan look decisive. If you have a defensible threshold based on operating costs or risk, record it. Otherwise, describe the pattern and the judgment it would support.

Leave room for an unexpected explanation. Prewriting possible actions should make your reasoning inspectable, not force every answer into a category you predicted.

6. Deadline and constraints

Fill in: “The evidence is needed by [date]. We can spend [budget] and reach [available audience]. The decision also depends on [operational constraints]. If we cannot get sufficient evidence in time, we will [fallback].”

A deadline might mean the study can inform a limited test but cannot justify a permanent change. Say so. A small budget doesn't make a narrow sample representative, and an approaching meeting doesn't make uncertain evidence conclusive.

Example: should a team extend support hours?

Consider a fictional DTC team deciding whether to test evening support. Everything in this example is illustrative, not a customer case study.

The initial request is “Let's research customer satisfaction.” I would push back. A satisfaction score won't explain whether unavailable help is creating problems that an evening shift could resolve.

Here's the tighter brief.

Decision to make. Before the next staffing schedule is approved, the support lead must decide whether to run a limited evening-support test or keep the current hours. Existing ticket records contain timestamps, but the team doesn't know whether the submission time reflects when help was first needed.

Uncertainty blocking it. The primary research question is: “On recent occasions when customers could not get help outside our staffed hours, what problems did the delay create that evening support could reasonably address?”

Relevant people. Recent customers who tried to get help outside staffed hours, including those who waited until the service reopened. Recruitment should reach beyond completed tickets where possible, so people who gave up before contacting support have a chance to participate.

Evidence needed. A small survey will collect accounts of recent occasions: when the need arose, what the customer was trying to resolve, how long they could wait, and what happened without help. The team will compare these accounts with ticket timing and issue types. This targeted study can describe problems among respondents; it cannot estimate their prevalence across all customers or prove that longer hours would increase sales.

What different findings would change. If accounts repeatedly describe time-sensitive problems that an evening agent could resolve, and the operational records support enough demand, the team will consider a limited test. If the problems mainly require warehouse action unavailable that evening, it will examine the handoff or expectations instead. If the evidence is too thin, it will gather broader demand evidence before committing staff.

Deadline and constraints. Findings are needed before the staffing schedule is approved. The support lead must also check coverage costs and what an evening agent would actually be authorised to resolve. The available decision is a reversible test, not a promise of permanent extended hours.

Notice how much this leaves outside the study. That's deliberate.

Questions for a later study

Keep a parking list beside the brief so useful ideas aren't lost:

• How satisfied are customers with support overall?
• Which support channels do customers prefer?
• How easy is the returns process?
• Does the help centre cover the right subjects?

Those questions deserve their own decisions and evidence plans. A return problem might appear in the current study because it explains an occasion when help was unavailable. That doesn't give the team permission to turn the study into a full evaluation of returns.

Using the brief with Probe

The brief is a planning document you can write outside Probe. I'm recommending a workflow here, not describing a built-in decision-brief feature.

Once the scope is agreed, you can use Probe to design a survey or interview study. We let you send a study to your own audience, with own-audience studies free up to 10 questions and 25 responses. Or we can recruit participants from our recruitment partner's vetted panel, with one all-in price per study shown before launch.

The relevant-people field should guide that choice. A general panel audience won't automatically have recent experience with your support team. For the fictional example, reaching your own customers would be the more direct route to the evidence described.

Results come back as charts, themes and quotes. Read them against the brief: which uncertainty does each finding reduce, and which possible action does it support? A clear chart doesn't expand what the sample can tell you. Neither does a memorable quote.

If the brief reveals that you need a population estimate rather than accounts of particular experiences, revisit the sampling plan before launching. How Many Survey Responses Do You Actually Need? covers that separate question.

The final check before recruitment

Put two plausible, opposing findings in front of the decision owner. Ask what they would do in each case.

If the answer is the same, clarify the purpose before recruiting. You may need to change the uncertainty, narrow the available decision, or acknowledge that you're documenting a choice already made.

Open a blank page and finish this sentence first: “When the findings arrive, I need to decide whether to…”