How to find research papers on a topic

A research question carries constraints that keywords cannot: a population, a mechanism, an outcome, a comparison, a time window, sometimes a method you will accept and a method you will not. Reducing it to three terms discards all of that and asks the database to guess which of the discarded constraints mattered.

The failure is invisible, which is what makes it expensive. A keyword search always returns results. It returns work that shares vocabulary with your question rather than work that bears on it, and nothing in the result list tells you that the paper solving your problem used a completely different word for the thing you called an outcome.

This is worst in fields where one concept has several established names, and in interdisciplinary work where the relevant result was published under a vocabulary you have never read. A materials scientist and a chemical engineer can spend a decade on the same phenomenon without either one matching the other set of search terms.

Before opening a database, write one sentence stating what you need to establish and what you would accept as an answer. It takes two minutes, and it is the only step that changes the outcome of every step after it.

A workable question names most of these:

• The subject — the population, material, system or dataset the claim is about.
• The intervention or mechanism — what is being done, changed, or measured.
• The comparison, if there is one — against what baseline, alternative or control.
• The outcome — what result would settle the question, and in what units.
• The boundaries — dates, languages, study designs and scales you will and will not accept.

Clinical and health fields formalise this as PICO. The framework is not the point; naming the constraints explicitly is. Do it in prose if a framework feels like overhead.

Each path has a different failure mode. Running one of them well still leaves a systematic blind spot, and running all four takes less time than most people spend refining a single query.

1. Term-based coverage. A structured query in a large index — Scopus, Web of Science, PubMed, or the subject database for your field — using controlled vocabulary where it exists. This path is exhaustive within the vocabulary you thought of, and blind outside it.
2. Semantic search. Describe the question in prose and let retrieval match on meaning. This surfaces work that used different words, which is precisely what the first path cannot do. It is weaker on completeness, so it complements rather than replaces path one.
3. Citation chasing. Take two or three papers you already know are on target. Read their reference lists backward, and find everything citing them forward. This is the highest-yield path per minute of effort, and the one most often skipped.
4. Venue scanning. Identify the three or four journals, conferences or preprint categories where this work actually appears, and read a year of their tables of contents. Slow, but it finds the recent work that nothing cites yet.

The four paths overlap heavily when the search is going well. That overlap is not waste — it is the evidence that you are approaching saturation, and it is the only reliable signal you get.

A large share of research questions are answered somewhere other than a peer-reviewed paper, and searching only for papers guarantees you never find those answers.

Theses are underrated for a specific reason: a dissertation chapter documents the approaches that did not work, which almost never survives into the paper. If you are choosing between three methods, that chapter is worth more than the three papers reporting success.

Not at a paper count, and not when the result list runs out. Stop at saturation: the point where a new search path, run properly, returns work you have already seen.

In practice that means running one deliberately different query — different vocabulary, a different database, a citation sweep from a paper you found late — and recording how many genuinely new relevant items it produced. Two or three consecutive attempts yielding nothing new is a defensible place to stop. One is luck.

Log the database, the exact query string, the date and the number of results as you go. Reconstructing a search a month later is far harder than logging it, and if the work is ever published as a review, the search is part of the method and has to be reportable.

The same log is what lets you answer a supervisor or a reviewer asking whether you looked for a specific thing. Without it, the honest answer is always that you do not remember.