Framing a research paper: abstract and introduction

Framing is what the abstract and introduction of your paper do. They are what a reviewer, an area chair, or a casual reader will decide the paper's fate on — often before reading a single equation. Get the framing right and the rest of the paper has a chance; get it wrong and even a technically excellent contribution reads as unimportant or confusing.

Two kinds of novelty: conceptual and technical

A good paper has both conceptual and technical novelties, and the framing should make both explicit.

Conceptual novelty is the novel direction or approach you take for the task — the “we look at this problem differently” part. It is the reason someone might want to work in this direction after reading your paper.
Technical novelty is the argument that this new direction is not trivial to make work. It is what justifies the technical machinery you introduce later.

The two are linked but distinct. Once you have convinced the reader that your direction is exciting (conceptual), you still need to convince them to keep reading — otherwise they will miss the non-trivial technical contributions that come after. A common failure mode is a paper with a great conceptual pitch that then reads as if the implementation was easy; readers stop paying attention. Another failure mode is a paper full of technical detail with no conceptual framing; readers cannot tell why any of it matters.

Abstract vs. introduction: WHAT vs. WHAT + WHY

Before diving into either, keep the split in mind:

The abstract answers WHAT — the task, the approach, and the main result, in a compact form.
The introduction answers WHAT + WHY — not only what the paper does, but why the reader should care about the task, and why you did what you did instead of what everyone else does.

The two sections have different jobs. The rest of this page treats them separately.

Writing the abstract

Keep the abstract focused on WHAT: the task, the approach, and the main result, in a compact form (typically 100–200 words).

The most common mistake is smuggling in too much WHY. Motivation, justification, and defense against alternative approaches belong in the introduction, not the abstract. Before you keep a sentence, ask: does this help the reader understand what the paper does, or is it defending the paper against an imagined critic? Only keep it if it serves the former.

Some contrast with prior work is legitimate — occasionally the clearest way to describe what you did is to say what you did not do (“unlike prior work that requires paired training data, we train on unpaired images”). The rule is:

Contrast only when it makes the WHAT clearer, not to preemptively argue that your WHAT is better.
If you can explain the WHAT without contrasting, do so. A crisp positive description usually beats a comparative one.
If contrasting genuinely clarifies, keep it short and factual, not evaluative.

A useful test: can every sentence in your abstract be read as a plain statement of what the paper does or achieves? If a sentence only makes sense as a justification, it probably belongs in the introduction.

Writing the introduction

The introduction has to do much more than the abstract: motivate the task, position the paper against prior work, and set up the reader for the technical content that follows.

A common failure mode is writing the introduction as a longer abstract — describing the paper without motivating it. That is a missed opportunity. A reader who finishes the introduction should be able to answer, on their own: what problem you are solving, why it matters, what is wrong with current approaches, what you propose that is different, and why that different thing was not obvious.

Every paper is different and no template fits all of them. But the following 7-step outline has worked well for me in many kinds of papers. Treat it as a starting point, not a checklist to fill in mechanically.

1. Define the task and explain its importance

Define what the task is, and say why solving it matters (applications, downstream benefits, scientific interest).

Adjust the depth to your reader:

If the task is standard (e.g., object detection, image classification), skip the definition. Assume the reader knows it.
If the task is less standard (e.g., “detecting the exact moment a hand touches an object in egocentric video”, or “counting distinct groups of moving people in a crowd”), define it clearly, ideally with a figure or a concrete example.
If the importance is self-evident (curing cancer, reducing road fatalities), one sentence is enough; do not oversell it.
If the importance is not immediate (a niche subtask whose applications are indirect — for example, a method that generates IMU signals from video, or a method that verbalizes a scanpath in natural language), flesh it out with one or two concrete downstream uses so the reader can see what solving it unlocks.

Do not spend a page justifying a well-known task, and do not spend one sentence on a task no one has heard of. Match the effort to the reader's likely prior.

2. How this task is currently performed, and why it is not satisfactory

Summarize the dominant existing approach(es) at a high level — one to three sentences, not a related-work section — and identify the specific weakness that motivates your paper.

The weakness should be concrete (“existing methods assume the target object is fully visible, which fails in real egocentric video where the hand occludes 40% of interactions”) rather than rhetorical (“existing methods are limited”). A vague weakness sets up a vague contribution.

3. The proposed new direction or approach (conceptual novelty)

State, in a sentence or two, what you propose to do differently. This is the paper's conceptual pitch.

The right level of abstraction here is high — you are naming the direction, not describing the method. A reader should finish this paragraph knowing what you are trying to do, not how.

4. Why this new direction is not trivial (technical novelty)

Explain why the new direction is not straightforward to implement. What is the naive/obvious version of the idea, and why does it fail? What is the specific challenge that requires careful design or technical innovation?

This is the paragraph that keeps the reader reading. Without it, a reader who liked the conceptual pitch may decide “sounds nice, probably easy” and skim the rest. With it, they arrive at the method section already knowing what they should be looking out for.

If you cannot say what is non-trivial about your approach, that is a warning sign for the paper itself, not just the introduction.

5. Overview of the method

A short, high-level description of your method — how the pieces fit together, without diving into equations. One or two paragraphs, ideally accompanied by a teaser figure or an architecture diagram.

A useful test: can a reader who stops here summarize your method in one sentence? If not, tighten this section until they can.

6. Overview of the experiments and results

Briefly describe the experimental setup — what benchmarks, what baselines, what metrics — and state the headline results. Do not enumerate every number; save that for the experiments section. One or two sentences with the strongest, most defensible claim.

Do not hide caveats here that will surface in the experiments section. If your method wins on some settings and loses on others, say so; a reviewer discovering it later reads much worse than you disclosing it here.

7. Summary of contributions (optional)

Optionally, close the introduction with a short bulleted list of the paper's contributions — three or four bullets, each one line. This is common in vision/ML venues but not mandatory; if steps 3–6 already make the contributions obvious, you can skip it. When you do include it, avoid restating results as contributions (“we achieve state-of-the-art on Dataset X” is a result — the contribution is the method or insight that produced it) and do not pad the list with filler like “we conduct extensive experiments”.