How to Write a Technical Research Paper: An IMRaD Step-by-Step Guide
A technical research paper is one of the most demanding forms of technical writing: it must present novel work precisely enough that another expert could evaluate or reproduce it, persuasively enough that reviewers accept it, and clearly enough that a busy reader grasps the contribution in minutes. Whether you are writing for an academic conference, a peer-reviewed journal, or an engineering-focused venue, the same underlying craft applies — and most of it is learnable structure rather than innate talent.
This guide walks through writing a technical paper step by step, using the IMRaD structure that dominates scientific and engineering publishing. It is aimed at researchers, engineers writing up experiments, and technical writers who support them. The principles connect to the broader craft covered in our beginner's guide to technical writing, and the editing discipline overlaps heavily with our article on crafting clear technical narratives. For style conventions in scientific and technical prose, the Google style guidance on clear, concise writing is a useful companion even outside software.
What a Technical Paper Actually Is
A technical paper is an argument, not a report. Beginners often treat it as a chronological account of what they did — "first we tried this, then that broke, then we tried the other thing." That is a lab notebook, not a paper. A paper makes a claim (a contribution) and marshals evidence to support it, structured for the reader's evaluation rather than the author's history. The reader's core questions are always the same: What is new here? Why should I believe it? Why does it matter? Every section exists to answer one of those.
This reframing changes everything about how you write. You do not include something because you did it; you include it because it supports the contribution or is needed to evaluate it. Dead ends, false starts, and irrelevant detail are cut. The paper is engineered backward from the claim you are making, and its structure — introduction, methods, results, discussion — is a standardized machine for delivering that argument in the order reviewers expect. Understanding this saves you from the most common failure: a paper that describes work thoroughly but never makes clear what it contributes.
The IMRaD Structure Explained
IMRaD stands for Introduction, Methods, Results, and Discussion — the near-universal skeleton of empirical technical papers. Each section answers a specific question. The Introduction answers "What problem are you solving and why does it matter?" It establishes the context, identifies the gap in existing work, and states your contribution. The Methods section answers "What exactly did you do?" in enough detail that a peer could reproduce it. The Results section answers "What did you find?" — the evidence, presented factually without interpretation. The Discussion answers "What does it mean?" — interpreting the results, acknowledging limitations, and situating the work in the field.
The power of IMRaD is that it matches how expert readers actually consume papers. Reviewers rarely read linearly; they read the abstract, jump to the figures in Results, check the Methods to see if the work is sound, and read the Discussion to judge significance. Writing to this structure means placing what each reader wants exactly where they will look for it. The structure also enforces a healthy separation that beginners routinely violate: keep interpretation out of Results and keep new results out of Discussion. Results is what you observed; Discussion is what you think it means. Blurring the two makes a paper feel unreliable.
Framing Your Contribution
The most important sentence in your paper is the one that states your contribution, and it belongs near the end of the introduction. A strong contribution statement is specific and honest: "We present X, a method that achieves Y under conditions Z, improving on the prior state of the art by W." Vague contributions ("we explore the space of...") signal to reviewers that the authors themselves are unsure what is new, which is fatal. Before you write anything else, force yourself to complete the sentence "The novel contribution of this paper is ___" in one clear line. If you cannot, the paper is not ready to write.
Framing also means positioning against related work fairly and precisely. Reviewers are often the authors of the work you are building on, so mischaracterizing prior approaches — or ignoring an obvious competitor — is both an ethical problem and a fast rejection. Situate your contribution as a specific advance over specific prior work, acknowledging what those approaches got right and stating exactly where yours differs. This precision is itself a form of credibility: a paper that understands its field deeply reads as trustworthy before the reviewer has even reached the results.
Writing Methods and Results
The Methods section lives or dies on reproducibility. Write it so that a competent peer in your field could recreate your work from the description alone: specify the setup, the parameters, the datasets, the versions, and the procedures precisely. Use past tense (you are describing what was done) and enough structure — subsections, numbered steps, or pseudocode — that a reader can follow the logic without hunting. Resist the urge to justify choices here; save the "why it works" for the discussion. Methods is the recipe, stated plainly.
Results should present your findings as clearly and neutrally as possible, letting the data speak. Lead with the most important result, and design your figures and tables to carry the argument — a good figure is often the first thing a reviewer looks at, so it must be self-explanatory, well-labeled, and honest about scale and uncertainty. Report negative and unexpected results too; they strengthen credibility. Crucially, do not interpret here — state what you observed ("accuracy increased by 12%"), not what it means ("this demonstrates the superiority of..."). That interpretive move belongs in the discussion, and keeping the two apart is a hallmark of professional technical writing.
The Abstract and Introduction Last
Counterintuitively, write your abstract and introduction last, once you know exactly what the paper says. The abstract is the most-read and least-carefully-written part of most papers, which is a mistake — for most readers, the abstract is the entire paper, and it determines whether anyone reads further or cites you. A strong abstract compresses the whole argument into a few sentences: the problem, the gap, what you did, what you found (with a concrete number if possible), and why it matters. It should stand alone and contain no filler.
The introduction expands the abstract into a full argument. A reliable pattern is the funnel: open with the broad problem and why it matters, narrow to the specific gap in current knowledge or capability, then state your contribution and briefly preview the paper. Many strong introductions follow a four-move rhythm — establish the territory, establish the niche (the gap), occupy the niche (your contribution), and map the paper. Writing these sections last means they accurately reflect the paper you actually wrote, rather than the one you planned to write. For the surrounding discipline of planning and structuring longer documents, see our guide to documentation strategy.
Surviving Peer Review
Peer review is where technical papers are made or broken, and approaching it well is a skill in itself. First, self-review ruthlessly before submitting: read the paper as a hostile reviewer would, hunting for the weakest claim, the missing baseline, the unclear figure. Most rejections cite problems the authors could have caught themselves. Anticipate the obvious objections and address them in the paper — a limitations subsection that honestly names weaknesses disarms reviewers far better than pretending none exist.
When reviews come back, treat them as data, not as attacks. Respond to every point in a structured rebuttal, make the changes you can, and argue respectfully where you disagree, backing your position with evidence. Reviewers who did not understand something usually indicate a clarity failure in the writing, not a comprehension failure on their part — so fix the prose rather than blaming the reader. This iterative revision is normal and expected; even excellent papers rarely land on the first try. If you want structured practice, Darlo's Technical Paper Writing course walks through drafting each IMRaD section and preparing for review, and includes a downloadable IMRaD paper template with section prompts and a pre-submission checklist. Explore it at /courses.
IMRaD Technical Paper Template & Pre-Submission Checklist
A structured IMRaD paper template with section-by-section prompts, plus a pre-submission checklist covering contribution clarity, reproducibility, figure quality, and reviewer-proofing.
What does IMRaD stand for and why use it?
IMRaD stands for Introduction, Methods, Results, and Discussion — the standard structure for empirical technical and scientific papers. It works because it matches how expert readers actually consume papers, placing each piece of information exactly where a reviewer expects to find it, and because it enforces a clean separation between what you observed and what you think it means.
Should I write the abstract first or last?
Last. The abstract must accurately compress the entire paper — problem, gap, method, findings, and significance — which you can only do once the paper is written. Writing it first almost always produces an abstract that describes the paper you intended rather than the one you actually delivered. The same applies to the introduction.
How do I handle harsh peer-review feedback?
Treat reviews as data, not attacks. Respond to every point in a structured rebuttal, make the changes you can, and argue respectfully where you disagree, backed by evidence. When a reviewer misunderstood something, that usually signals a clarity problem in your writing to fix, not a failure on their part. Iterative revision is normal even for strong papers.