How to Build a Research Vocabulary Before Searching Databases

You sit down to search a database, type your topic into the box, and get either a flood of irrelevant records or almost nothing. The problem is usually not the database. It is that you are searching with the words you happen to know, not the words the literature actually uses. Building a research vocabulary before you search means assembling the terms, synonyms, and controlled subject headings that describe your question, so that your first real search is deliberate rather than exploratory guesswork.

This guide gives you a complete sequence: diagnose where you are starting, build the vocabulary artifacts, test them, and know when the vocabulary is ready to drive a search. It uses a winter-break cleanup and January project-start scenario, because that is when many students and early-career researchers turn a finished paper into a new project.

The Cochrane Handbook's guidance on searching for studies starts from eligibility criteria, not from keywords. That ordering matters: you decide what counts as a relevant study, and the vocabulary follows from that definition. Cochrane also recommends combining free-text terms with subject headings and documenting the search process. In practice, that means your vocabulary has at least two layers — the words authors write in titles and abstracts, and the standardized headings a database assigns to records.

PubMed's user guide reinforces the same idea from the database side. It supports field tags, phrase searching, filters, and Advanced Search, and its search details show how your terms were translated and combined. That translation step is exactly where a thin vocabulary fails: if you only supply one phrasing, the database has little to work with.

So the goal of this pre-search phase is a small, documented term set you can defend, not a perfect list. You are building something you will revise after the first search, not something you finish in one sitting.

Before building anything, work out which of these describes you. The right next move differs by starting point.

• You have a topic sentence but no terms. You can describe your project in a paragraph but cannot list the words a paper on it would use. Start with the concept-mapping step below.
• You have a pile of papers but no structure. You have read broadly and saved PDFs, but you cannot say which terms recur. Start by mining those papers for vocabulary.
• You have supervisor feedback but no direction. Comments like "narrow your question" or "engage the literature" usually mean the concept boundaries are unclear. Start by writing eligibility criteria.
• You have a finished project and a new one beginning. This is the winter-break cleanup case: you are carrying vocabulary from the old project that may not fit the new one. Start by separating inherited terms from new ones.

A quick self-check: can you write down three synonyms for your central concept, plus one standardized heading you have seen attached to a relevant paper? If not, you are still in the diagnosis stage.

Following Cochrane's logic, write down what a study must contain to be relevant to you. Keep this short — three to five inclusion points and one or two exclusions. For a January project start on, say, how remote work affects early-career mentoring, your criteria might specify the population (early-career employees), the exposure (remote or hybrid arrangements), and the outcome (mentoring access or quality).

This step does two jobs. It forces you to name the concepts that need vocabulary, and it gives you a test for later: when a new term appears, ask whether it maps onto one of your criteria. Terms that do not map are noise, even if they are interesting.

Write the criteria somewhere you will keep them. They become the spine of your vocabulary table.

Build a simple table with one column per concept from your criteria. Under each concept, collect terms in three rows: the words you would use, the words other authors might use, and standardized headings. Leave the heading row empty at first if you do not know any — you will fill it from real records.

This table is your central artifact. Everything else in this guide either feeds it or tests it. Keep it in a document you can revise, not in your head.

You do not need a database search to start collecting terms. Take five to ten papers you already know are relevant and read them for vocabulary rather than for findings. Harvest three things:

1. Title and abstract phrasing. Note how authors describe your concept. Variants you would never have typed often appear here.
2. Author keywords. Many papers list them explicitly; these are the authors' own vocabulary choices.
3. Subject headings. If a record shows standardized headings, copy them into the heading row of your table.

If your trusted papers are scattered across folders, this is a good moment to consolidate them. Saving or uploading papers into My Library gives you one place to organize the set you are mining, so the vocabulary work and the reading list stay together.

Checkpoint: after this step you should have at least two author variants per concept. If a concept has only one term, you have not mined enough papers yet.

Now run a deliberately exploratory search. The purpose is to see how the database translates and combines your terms, and to harvest new vocabulary from the records it returns.

PubMed's search details are useful here because they reveal how your terms were translated and combined. Read that translation. If the database mapped your phrase to a heading you did not expect, add that heading to your table. If it split your phrase, note the split and adjust.

For a broader sweep, a scholarly search interface lets you scan titles and abstracts quickly for recurring phrasing. Running your concept terms through WisPaper search is one way to find academic papers and read their vocabulary before you commit to a formal search string. Treat the results as a term source at this stage: you are looking for words, not yet building a reference list.

Checkpoint: your heading row should now have at least one standardized heading per concept, drawn from real records rather than guessed.

Different databases expose vocabulary in different ways, and knowing the tools shapes what you collect.

PubMed supports field tags, phrase searching, filters, Advanced Search, saved searches, Similar Articles, and citation lookup. Similar Articles is a vocabulary shortcut: it surfaces records related to one you already trust, and their phrasing can extend your table. Saved searches matter later, once your vocabulary stabilizes.

Google Scholar documents searching by author and title, date sorting and limits, Cited by and Related articles, citation export, library access links, email alerts, and ways to locate alternative versions of a work. Its Related articles feature serves the same vocabulary-expansion role as PubMed's Similar Articles.

Cochrane's guidance adds two process points worth building in now: use multiple sources, and plan to rerun searches before publication. If you intend to rerun, your vocabulary needs to be documented well enough that you can reproduce it months later. That is why the table, not the search box, is the artifact you keep.

Suppose you finished a course paper in December on team communication and are starting a thesis chapter in January on remote work and mentoring. Here is how the sequence plays out.

Diagnosis. You have a topic sentence and a folder of papers from the old project. You are in the "finished project, new one beginning" state.

Criteria. You write: population is early-career employees; exposure is remote or hybrid arrangements; outcome is mentoring access or quality. You exclude studies of mentoring among executives only.

Concept map. You build the three-column table above. Your own terms are thin — you would have typed "remote work" and "mentoring" and stopped.

Mining. You pull eight papers from your old folder that touch on communication in distributed teams. Their abstracts use "telework," "distributed teams," and "developmental relationships." You add these to the author-variant row. You notice your old project's vocabulary was about communication channels, not mentoring, so you mark those terms as inherited and set them aside.

Exploratory search. You run the concept terms and read the search details. The database maps one phrase to a standardized heading you had not considered. You add it to the heading row.

Expansion. You open Similar Articles or Related articles on your most trusted paper and harvest two more variants.

Readiness check. You now have three variants per concept, at least one heading per concept, and a documented table. The vocabulary is ready to drive a formal search.

Use this checklist as a stop rule. You are ready to move from vocabulary building to formal searching when all of the following are true:

• Every concept in your eligibility criteria has its own column.
• Each concept has at least two author variants, drawn from real papers.
• Each concept has at least one standardized heading, drawn from a real record.
• You have read how the database translated your terms at least once.
• Your table is saved somewhere you can revise and revisit.
• You can explain why each term maps to a criterion.

If a concept still has only one term after mining and one exploratory search, that is your signal to stop and read more papers on that concept specifically, rather than pushing ahead with a thin search.

Vocabulary is not a one-time artifact. Cochrane's recommendation to rerun searches before publication implies that your term set will change as the project develops. Two habits keep it current.

First, when you read a new paper, add any new phrasing to the table immediately. A term you notice but do not record is a term you will lose.

Second, when your reading raises questions you want answered across your saved papers, ask them against that collection rather than re-searching from scratch. Library QA lets you ask questions based on papers uploaded to My Library or added from search results, which keeps the vocabulary work connected to the papers that generated it.

If your project grows into a longer literature review, the vocabulary table becomes an input to that work rather than a separate task. Scholar Agent supports longer research tasks in the literature review, inspiration, and reproduction areas, which is where a documented term set pays off.

• Searching with one term per concept. Correct it by returning to Step 3 and mining more papers. One term cannot carry a concept.
• Collecting terms without criteria. If your table has columns that do not map to eligibility criteria, you have drifted. Cut them or rewrite the criteria.
• Guessing standardized headings. Headings must come from real records. If you cannot find one, leave the cell empty and keep mining.
• Losing the table. A vocabulary you cannot reproduce is a vocabulary you cannot rerun. Keep it in a document, not a scratchpad.
• Treating the first search as final. The first search is for discovery. The formal search comes after the readiness checklist.

Pick the concept in your table with the fewest terms. Open three papers you already trust that address that concept, and harvest every variant and heading they use into the table. Then run one exploratory search on that concept alone and read how the database translated your terms. When that single column passes the readiness checklist, repeat for the next concept. The vocabulary is ready when every column passes — and that is the moment to write your formal search string.