How to Write a One-Page Research Brief for Stakeholders

Research projects rarely fall apart at the method stage. They fall apart earlier, at the kick-off, when four people walk into the same room with four different ideas about what is being answered. One sponsor expects a competitor review, another expects a list of feature requests, and the researcher quietly plans a set of interviews that will satisfy none of them.

A one-page brief prevents most of that. It is not a proposal, and it is not the summary you write afterwards. It is a working document: the question, the approach, the dates, and the change the work is meant to cause.

One page is also a useful honesty test. If it will not fit on a single sheet, you are usually looking at two projects, not one.

The five blocks that earn their space

Almost every brief needs the same five things. Keep them in this order and the page reads quickly, even to someone who has thirty seconds between meetings.

1. The decision. One sentence naming the choice this work informs, and who owns that choice.
2. The questions. No more than three, phrased so that a real answer is possible.
3. The approach. Method, who you will speak to or observe, and roughly how many.
4. The timeline. Brief agreed, recruitment complete, fieldwork complete, analysis drafted, readout, decision.
5. The output. What lands on people's desks, in what format, and what happens to it next.

Everything else — background reading, team biographies, a history of previous studies — belongs in an appendix nobody reads on the first pass. If a stakeholder needs the background to understand the brief, the brief is doing too much work.

Start with the decision, not the topic

"We should do some research on onboarding" is a topic. It has no shape, no end point and no way to fail. Turn it into a decision and the whole page sharpens.

For example: By 14 March we will choose between keeping the current free trial or moving to a paid pilot for new sign-ups. Now the research question has edges. Something like: What convinces someone to keep going past day three, and what makes them stop?

That question names a moment, a behaviour and a group of people. Anyone reading it can imagine what a useful answer looks like, and anyone can tell when the answer has arrived.

Write questions that can be answered

Vague questions produce vague research. Before you commit a question to the page, run it through three checks.

• Is it answerable with the time, budget and access we actually have?
• Would two reasonable people agree on what a good answer looks like?
• Does it name a behaviour, moment or group rather than a general mood?

Before and after

"How do users feel about our pricing?" becomes "When people see the pricing page for the first time, what do they believe is included, and where does that belief come from?"

Avoid compound questions joined by "and". Split them. Avoid questions that contain their own answer, such as "Why do customers find the sign-up flow confusing?" — you have already decided they do. And resist the urge to ask three versions of the same thing in the hope that one of them works.

Match the method to the question

The method should follow from the question, not from habit. A short guide:

• To understand why something happens: interviews, diary studies, session recordings.
• To understand how many or how often: a survey, event data, or an analysis of existing support tickets.
• To understand how something works in the moment: moderated usability sessions or field observation.
• To test a specific change: a small experiment with a measure agreed in advance.

Be honest about what the method can carry. A handful of interviews will show you the range of reasons people behave a certain way; it will not tell you which reason is most common. Decide which of those you need before you choose the method, because the two require very different plans.

Name the sample plainly

Write "eight to ten people who signed up in the last month and abandoned setup", not "users". Recruitment is usually the slowest part of any study, so agreeing the exact profile early saves a fortnight of chasing. If you cannot recruit that profile, you need to know now rather than three days before fieldwork.

Build the timeline backwards from the decision

Start with the date the decision has to be made. Subtract the readout, the analysis, the fieldwork and the recruitment window. What remains is the earliest you can start, and it is often earlier than anyone expected.

A workable one-page timeline lists six dates and no more, each with a name beside it:

1. Brief agreed and signed off
2. Recruitment complete
3. Fieldwork complete
4. Analysis drafted and shared with the team
5. Readout with stakeholders
6. Decision made

Leave a day of slack before the readout. Recruitment slips, participants reschedule, and a transcript arrives late. A brief that assumes everything runs perfectly is a brief that will be rewritten in week two.

Say what will land — and what will not

People agree to research more readily when they know exactly what they are getting. Be concrete. A 30-minute readout on 12 May. A two-page written summary in the shared folder the same week. A prioritised list of friction points, each with a supporting clip from a session. Not "insights" and not "a report".

Just as useful is a short line about limits. This will not tell us how many customers would pay for the feature, or whether it is technically feasible. Stating the boundary up front prevents the awkward moment in the readout when someone asks the question you never set out to answer — and it makes the things you did answer feel more solid, not less.

Finish the page with two lines: who receives the output, and which decision it feeds. Then anyone picking up the brief months later knows why it existed.

Circulate it, agree it, then start

Send the draft to everyone who will attend the readout, not just the sponsor. Ask two questions: is this the right decision, and is anything missing that would change how you act on the answer? Give people 48 hours, then make the edits yourself rather than collecting comments in a meeting. A brief that has been argued over once, in writing, is worth more than a plan presented to a silent room.

Once agreed, keep the page visible — pinned at the top of the project channel, dated, with a version number. If the question changes halfway through, rewrite the page and tell everyone. If a date slips, update it. A brief that quietly goes stale is worse than no brief at all, because people plan around it.

Finally, make it easy to find. Boring file names, one folder, one format every time. A one-page brief that takes twenty minutes to write, read and challenge is one of the highest-value habits a research team can build — and it costs nothing but a decision about what genuinely matters.

Photo: hudsoncrafted / Pixabay