Every researcher has a folder like it. It's called analysis_final_v2_FINAL_use_this.xlsx, it sits next to four near-identical siblings, and nobody, including the person who made it, is completely sure which one produced the table in the submitted paper. It works, sort of, until a reviewer asks for a revision eight months later, or a new student joins the project, or the laptop dies.
Organizing research data isn't a talent some people have. It's a small set of decisions you make once, at the start of a project, and then stop thinking about. This guide covers the five that matter: folder structure, file names, versioning, documentation, and backup. None of them require special software, and all of them pay off the first time you have to find something six months later.
Decide the folder structure before the data arrives
The single most useful habit is separating raw data from everything derived from it. A structure like this covers most projects:
data-raw/: files exactly as collected or received. Nothing in here ever gets edited. If a raw file is wrong, you fix it in code or in a documented cleaning step, not by opening the original and typing.data-clean/: the processed datasets your analysis actually uses.code/orscripts/: everything that turns raw into clean, and clean into results.results/oroutput/: tables, figures, model outputs.docs/: the README, data dictionary, consent forms, protocol notes.
The read-only rule for raw data is the piece people skip and later regret. When the raw files are untouchable, every result is reproducible: anyone can rerun the pipeline from the originals and get the same answer. When they aren't, the project's history lives only in someone's memory.
Name files so they sort and explain themselves
A good file name tells you what's in the file without opening it, and sorts into a sensible order in any file browser. Three rules get you there:
- Dates go first and in ISO format:
2026-03-14_interview-notes_site-a.txt. Year-month-day is the only date format that sorts correctly as text. "March notes final" doesn't sort and doesn't say which March. - No spaces or special characters. Use hyphens or underscores. Spaces break scripts and command lines; slashes, colons, and question marks break some operating systems entirely.
- Be consistent, not clever. Pick a pattern like
date_project_content_versionand write it down in the README. The pattern matters less than everyone on the project using the same one.
Version deliberately, whichever way you choose
The "final_v2_FINAL" problem is a versioning problem. There are two honest solutions and both work:
Manual versioning: number versions in the file name (_v01, _v02), never reuse a number, and when a version becomes the one that matters, note in the README which version fed which output. Move superseded files into an old/ subfolder so the working folder shows only the current state.
Version control: if your work is script-based, a tool like Git records every change with a date, an author, and a note, and lets you recover any earlier state. It has a learning curve, and it's not designed for very large data files, but for code and text it's the standard for a reason. Many researchers land on a hybrid: Git for code, manual versioning for data.
The test of any versioning scheme is a single question: can you point, with certainty, to the exact files that produced the results in your last paper? If yes, your system works. If you'd have to reconstruct it, it doesn't.
Write the README while you still remember
Documentation sounds like a chore because people imagine writing it at the end, about a project they've half forgotten. Written at the start and updated as you go, it's twenty minutes of work. A working README answers four questions (the dataset README guide has a fuller template for data you plan to share):
- What is this project, in two sentences, and who worked on it?
- What does each folder and important file contain?
- For each dataset: where did it come from, when, and what does each variable mean, including units and codes? (This part is the data dictionary. For a survey, it's the question text, the variable name, and what each response value stands for. The codebook guide has a template.)
- In what order do the scripts run to reproduce the results?
The audience for this file is a specific person: you, in two years, or the student who inherits the project. Write for someone smart who knows nothing about your folder logic, because that's exactly who will read it.
Back up like the laptop is already gone
The standard advice is the 3-2-1 rule: three copies of anything you can't recollect, on two different kinds of storage, one of them somewhere else. In practice, for most academic projects, that means the working copy on your machine, an automatic sync to institutionally managed storage, and the untouched raw originals in a third location. The key word is automatic. A backup routine that depends on you remembering it isn't a routine; it's a hope.
Two cautions. If your data involves human subjects, where you may store it is an ethics and policy question, not just a convenience question: personal cloud accounts are usually the wrong answer, and your IRB protocol or institutional policy likely names the right one. And a sync service alone is not a full backup, since a file deleted or corrupted on your machine syncs its way into the copy. Versioned or periodic snapshots are what let you reach back in time.
Close the project while it's still warm
When the paper is out or the project ends, an hour of tidying preserves years of work: delete the true junk, move the superseded versions to an archive folder, update the README so it matches reality, and export anything trapped in a proprietary format to an open one (CSV alongside the statistical package file, plain text alongside the vendor format). If your funder or journal expects the data to be deposited in a repository, this is the moment it's cheap to do, because everything a curator will ask for is the list above.
Start smaller than you think
If a full system feels like too much in the middle of a busy semester, do three things this week: make the raw-data folder read-only, put dates in ISO format at the front of new file names, and start a README with whatever you'd want a stranger to know. Those three habits catch most of the disasters. The rest can grow from there.
And if you're writing a grant, this is also the material your data management plan is made of: the plan is just these decisions, written down before the project starts. The two documents should agree with each other.