How to structure a paper¶
A paper makes and supports a focused research argument.
The reader should be able to answer:
- What problem are you investigating?
- Why does that problem matter?
- What is missing or uncertain in existing work?
- What did you do about it?
- What evidence did you collect?
- What can we reasonably conclude from that evidence?
The exact structure varies between fields and venues, but the following is a useful starting point.
Title¶
The title should tell the reader what the paper is actually about. Include the important system, question, comparison or study context.
Avoid titles that are so broad they could describe an entire research field. A clever title is optional; an informative title is not.
Abstract¶
The abstract is a compressed version of the complete paper. It normally includes:
- the problem and context;
- the specific gap or question;
- what you built or studied;
- the method or experiment;
- the most important results; and
- the main conclusion or contribution.
Do not use the abstract as an introduction that stops just before anything interesting happens. Include the actual result.
I usually start with writing a rough abstract early to test whether the story is coherent, then rewrite it after the paper is complete.
Introduction¶
The introduction moves from the broader problem to the specific contribution of this paper.
A common flow is:
- establish the problem and why it matters;
- explain what current approaches can and cannot do;
- identify the specific unresolved question;
- state what this paper does; and
- summarise the contributions.
By the end of the introduction, the reader should understand why the work was necessary and what evidence the paper will provide.
Do not hide the research question.
Related work¶
Related work positions your paper within the existing literature. It should compare themes, methods, assumptions and evidence rather than giving one paragraph to every paper you read.
Use the workflow in Turn your notes into a literature review.
The final part should make the relationship to your work clear. Be precise about what is missing; do not claim that nobody has ever considered an idea merely because your first search did not find it.
Method or system¶
Explain what you built, changed or investigated in enough detail for the reader to understand and evaluate the work.
Depending on the paper, this may include:
- system architecture;
- hardware and software;
- algorithms;
- interaction design;
- data collection;
- model training;
- experimental conditions; and
- implementation decisions that affect the results.
Experimental setup or study design¶
Explain how the method was evaluated.
This may include:
- research questions or hypotheses;
- independent and dependent variables;
- baselines and comparison conditions;
- participants or datasets;
- tasks and procedures;
- apparatus;
- metrics;
- statistical analysis; and
- ethics approval or consent procedures where relevant.
Separate the method from the results. The reader should know how the evidence was produced before being told what it showed.
Results¶
Report the evidence clearly. Be factual, not boastful.
Use figures and tables when they make patterns or comparisons easier to see. Report appropriate units, uncertainty, sample sizes and statistical information.
Remember, not every result needs to be statistically significant, and an unexpected result is not automatically a failed experiment.
Discussion¶
The discussion explains what the results mean.
Connect the evidence back to the research question:
- Which expectations were supported?
- What was surprising?
- How do the results compare with prior work?
- What plausible explanations exist?
- What practical or theoretical implications follow?
- What should we not conclude?
Do not simply repeat the Results section.
Limitations¶
Every study has limits. State the ones that affect how the results should be interpreted or generalised.
Useful limitations are specific. For example:
- a small or narrow participant group;
- one robot, environment or task;
- a short exposure period;
- a simulated rather than real deployment;
- an imperfect baseline;
- measurement uncertainty; or
- an assumption that may not hold elsewhere.
A limitations section does not weaken honest research. Pretending the limitations do not exist does.
Conclusion¶
Return to the original problem and state what the paper has established.
It may briefly identify the most important next steps, but avoid ending with a long wishlist of every possible future project.