Write Your Methods and Results First (Using a Model Article)

Most people write their Methods and Results in the middle of the project, under pressure, at the worst possible moment. I want to argue for the opposite: write them first.

There's a good reason to start here. Methods and Results are the factual core of the paper. Everything else — the introduction, the discussion — is argument wrapped around them. And unlike the argument, they can be written the moment the analysis exists. You don't need to know what the paper means yet. You only need to know what you did and what you found.

I'm a fairly average researcher — a clinical psychologist who also does statistics — and I've written around twenty papers. I didn't write them by being unusually clever. I wrote them by getting the order right and by copying, deliberately, what my field already does. That's what this post is about: writing the two most factual sections first, and writing them the way your field actually expects rather than the way a textbook taught you.

This post covers the first half of that: finding a model article so you learn your field's conventions, then writing the Methods and Results sections around it. (The second half — building a document that reruns itself when your data changes — I've put in a companion post on making your analysis reproducible.)

The theme throughout is the same: don't reinvent. Copy the field's conventions, and spend your effort where it's actually scarce.

📄 Free: I've built a prefilled RMarkdown/Quarto notebook that implements this exact workflow — the document structure, placeholder Methods and Results prose, and the analysis scaffolding you write straight over. It's ready to download and start from. Get the notebook here.

Find your model article first

Most of us learn statistics the same way: textbooks, courses, YouTube. We work through the material carefully, understand the methods, sit down to write a Methods section — and then discover, usually through peer review, that what we were taught and what our field actually does are not quite the same thing.

Textbooks teach you what is statistically defensible. They don't tell you what your field considers standard. Those are different things, and the gap between them is invisible until someone points it out.

The fastest way to close that gap is to find one article that does roughly what you intend to do and use it as a template — not for the ideas or the argument, but for the structure, the statistical choices, and the reporting conventions. A model article shows you what your field considers basic. Once you have one, you stop guessing.

What to look for

You don't need the most-cited paper. You don't need one on the same topic. You need an article with roughly the same design — the same type of comparison, the same outcome type, the same number of groups — published in a journal you'd want to publish in. Those two criteria matter more than topical similarity. A study testing a two-group intervention on a continuous outcome is a better template for your two-group RCT than a famous meta-analysis on the same subject.

The selection doesn't take long. Three or four candidates are usually enough. Look at how they report the primary analysis:

• which statistic they lead with;
• what goes in the results table versus what goes in the text;
• how long the methods section is, and how much model detail it includes;
• whether they report effect sizes, confidence intervals, or both;
• what software they name.

None of this is random. It reflects what reviewers in that journal expect to see. (This is also the moment to sanity-check your design decisions — including whether your sample size and power are in line with what these papers report.)

If you're not sure where to start, ask your supervisor. A good supervisor can name a suitable model article in five minutes — and that five-minute conversation is worth far more than working it out alone.

The mistake I made instead

I learned this the hard way. Early in my PhD I'd spent a lot of time with statistics textbooks and developed a genuine interest in Bayesian methods. By the time I wrote my first article I was convinced this was the right approach — more principled, better suited to the uncertainty in my data. I used Bayesian statistics throughout.

When I sent the draft to my supervisors, their reaction surprised me. They weren't opposed to the Bayesian framework, but they were uncertain — they didn't know whether it was right or wrong here, because it wasn't what they were used to seeing. What they could see was that I'd skipped a number of things they considered straightforward and expected: reporting conventions, standard comparisons, effect sizes in the format the field uses. I'd reached past what the field expects and missed it entirely.

The Bayesian analysis wasn't wrong. But I'd skipped the model-article step, and I'd optimised for what a textbook recommends rather than what a field accepts. One afternoon with the right article would have shown me what basic looked like.

Write your methods around what you actually did

Every analysis tells two stories. What you did — the tests, the decisions, the sequence. And why you did it — why this test, why you handled missing data this way, why your sample size is what it is. Most methods sections keep only the first. The numbers are there; the reasoning has evaporated.

Good Methods writing keeps both stories, and keeps them readable.

With the model article open, the structure writes itself. Go to its data-analytic section and work through it line by line. Your Methods section follows the same sections, in roughly the same order, with the same reporting. For each analysis, you write a sentence or two describing what you did and — crucially — why, with a citation where the choice rests on a convention or a methodological decision.

That "why" is the part people skip, and it's the part reviewers ask about. Why multiple imputation instead of complete-case analysis? Why this test and not another? Why a correlation threshold of 0.2 and not 0.3? If the reason lives only in your head, it's gone in six months — and you'll be reconstructing it under deadline pressure when a reviewer asks. Write it down now, next to the decision it explains.

Two failure modes are common here.

The first is under-explaining — a methods section that lists what you did with no reasoning at all. It reads as a recipe, and it leaves every "why" for the reviewer to ask about later.

The second is over-explaining — a lengthy justification of a method that already has a canonical reference. That isn't a methods section, it's a poorly placed literature review. If the decision rests on a paper, cite the paper. If it rests on a guideline, point to it. One line of reason, or a pointer to where the reason lives, is enough.

The benefit of getting this right compounds. Every time I return to an analysis — sometimes years later — I can read the methods like a paper: what I did, and why. When a collaborator asks what we did, the answer is written down. When a reviewer asks why we chose an approach, the answer is already there, in the format the field expects.

You wrote the analysis once. Write the reasoning down once, too, and the document remembers it for you.

📄 Free: Don't start Methods from a blank page. My prefilled RMarkdown/Quarto notebook gives you the section structure and placeholder prose you write straight over — modelled on exactly the conventions this post describes. Download the notebook here.

Write your results by stating, not interpreting

The Results section has one job: state what the analysis found. Not what it means. Not whether it's what you hoped for. Not a reassurance that the non-significant findings are still interesting. What it found.

In this order of writing, Results is the easiest section, because by the time you reach it the analysis is already done. Everything you need is a number you already have. A results paragraph looks the same each time: one sentence stating what you're reporting, the table, one sentence noting the key finding with the statistic. Then you move on. Same structure, repeated per analysis. (I go deeper on the one-sentence results paragraph in a separate post.)

The discipline is in what you leave out.

State, don't interpret

The first failure mode is adding interpretation. Explaining what a result means, hedging about a non-significant finding, noting that an effect "approached significance" — all of that belongs in the Discussion. Results states; Discussion interprets. It's harder than it sounds, because you're close to the work and you want to tell the reader what to make of it. Resist. The Discussion is where that goes.

Don't apologise for your results

The second failure mode is apologising — softening a null finding, framing a small effect as more than it is, adding language that quietly reassures the reviewer not to worry. A reviewer notices all of it, and it weakens the paper rather than strengthening it. State the result plainly. If it's non-significant, say so. A clean null, plainly stated, is more credible than a null dressed up as something else.

There's a deeper reason to keep Results factual and mechanical: it protects you on the day you're not calm. When your results are just a plain statement of what the analysis produced — no interpretation woven in, no hedging to maintain — there's far less to second-guess the night before a deadline. The section says what you found. That's the whole job.

State what you found. Save what it means for later.

Where this leaves you

You now have two of the hardest sections written, and written well: a Methods section that matches your field's conventions because you built it from a model article, and a Results section that states what you found without straying into what it means.

Just as importantly, you haven't polished a single sentence of argument yet — which is exactly right, because the argument hasn't been tested. Prose is expensive; structure is cheap. The next step is to build that argument the cheap way first, with a five-sentence skeleton, before you write a full introduction or discussion.

But there's one more thing worth doing before you move on, and it's the difference between a paper you dread revising and one you don't. Right now your Methods and Results describe a fixed analysis. The moment your data changes — a corrected file, a late entry, a reviewer's request — every number in these sections is at risk of going out of date. In the companion post, I show how to write these same sections in a document that updates itself: change the data, press one button, and every table and statistic re-runs. It's the single change that turned my own major revisions from days of work into minutes.

📄 Free: Set this up this week, not "someday." My prefilled RMarkdown/Quarto notebook has the full Methods-and-Results structure from this post ready to write over. Download it here.

What's the convention in your field that a textbook never told you about — the thing peer review had to teach you? Hit reply and tell me the one that caught you out. I read every reply.