Read the Methods First: A Mind Map Habit for Literature Reviews

If you work in ML or CS, your reading list probably grows faster than your notes. A dozen arXiv papers can all say "fine-tuning" or "retrieval-augmented" and still describe different experiments. The habit below treats each paper's methods section like a spec: you read it before you look at the results.

The problem that shows up in week three

You collect the PDFs for a literature review, read the abstracts, and keep notes in one document. A few weeks in, that document has become a long scroll of quotes and half-sentences, and you start grouping papers by the names they use for their methods.

At some point you notice that two studies you filed side by side, both described as "fine-tuning," were trained on different datasets and judged with different metrics. One reports accuracy on a balanced test set. The other reports F1 on a much smaller, skewed sample. They were never answering the same question, and your notes hid that.

Abstracts are written to sound comparable, so this is easy to miss. Changing the reading order fixes this: read each paper's methods section before anything else, give each paper its own map, and compare papers only at the end.

One paper, one map, methods first

Give every paper its own mind map, and build the first-level branches from the methods section rather than the abstract. For most empirical papers, five branches are enough:

• Data: the dataset or corpus, where it came from, and the time period.
• Sample: size, who or what was included, and how it was selected or split.
• Metrics: exactly what was measured, and on which test set.
• Baselines: what the method was compared against, and whether those baselines were retrained or copied from older papers.
• Conditions: settings that change the result, such as lab versus field, supervised versus self-supervised, or the compute budget.

Findings come later, as children of these branches. A result means little until you know the data and metric behind it.

To get a first draft quickly, you can run the PDF through a research paper to mind map tool. On MindLM, uploading a PDF needs a free account. If you only want to try it on a section, you can paste text or a link and generate a map without signing up. MindLM also has a free plan.

The generated map is a rough outline. Rename branches in your own words: "Evaluation" becomes "F1 on held-out tweets, Table 3," and "Approach" becomes the actual procedure. Renaming makes you read the section closely, and the labels you choose are the ones you will compare later. Note the page or table next to every number so you can find it again.

A MindLM map of the pre-training section of the BERT paper.

Spotting the same-named method with a different setup

Once you have a few maps, look for branches that share a label. A shared label is the easiest place to merge two papers that don't belong together. Before you write a sentence like "prior work fine-tunes transformers," open the methods section of every paper behind it and check four things:

1. Is the training data the same, or only similar in name?
2. Is the metric computed the same way, on a comparable test set?
3. Are the baselines the same, and run under the same conditions?
4. Did the authors change something they mention only in passing, such as preprocessing, filtering, or a different split?

If any answer is no, the papers belong in separate groups, even though their labels match. Write down the difference in one plain sentence. That sentence may end up in your related work section, because it explains why the results disagree.

When to start comparing

Wait to merge until every claim on every map traces back to a page or table in its source. If you can't find where a node came from, delete it or rewrite it as a question for yourself.

When you are ready, compare in a separate place: a new map, a table, or a page in your notes app. Keep the per-paper maps unchanged so you can return to the original. To compare, collapse the branches that don't matter for the current question and expand only the ones you are lining up, for example the metrics branch across five papers. With only those branches open, gaps are easier to see: one paper never reports a baseline, or two share a dataset but disagree on the result.

Build the groups around procedure. If the setups differ, split the group, even when the method names match.

What the maps won't do for you

A mind map shows you a paper's structure. The judgment calls below stay with you.

• Numbers and citations. Generated text can paraphrase loosely or drop a qualifier, so check every number you plan to cite against the PDF.
• Duplicate claims across papers. Deciding that two findings are the same result takes your reading of both methods sections.
• Your reference manager. Keep Zotero, or whatever you already use, as the record of what you read, and put the citation key in each map's root so every claim keeps its source.
• The author's framing. Related work sections are written to favor the paper's own contribution, and a map of that section carries the same slant.

A 20-minute starting exercise

You can test this habit before changing your whole process. Choose three papers you already know belong in your review, preferably ones you have grouped together.

Make one map per paper and fill in only the methods branches: data, sample, metrics, baselines, conditions. Spend about five minutes on each. Skip results for now.

Then put the three maps side by side and list every difference in setup you can find. An empty list confirms the grouping and leaves you with notes you can cite from. Anything on the list is a problem you caught before it reached your draft, and the next paper you add gets read the same way, methods first.

Originally published at MindLM.