Most research teams have a rigorous methodology and an improvised writing process. The experiment is preregistered, the analysis pipeline is scripted and reviewed — and then the paper itself is assembled from email attachments, three reference managers, a folder called final drafts, and one heroic co-author who merges everything at 2 a.m. before the deadline.
The cost is not just stress. Improvised writing processes produce real defects: inconsistent numbers between text and tables, citations that drifted away from the claims they support, contributor work lost in version collisions, and submission packages rebuilt from scratch for every journal. None of these are intellectual failures. They are workflow failures, and workflows can be fixed.
What follows is the structured workflow we see in teams that publish smoothly and repeatedly. None of it requires any particular tool — though we will be honest about where tooling helps — and all of it scales from a two-author short paper to a twelve-author consortium manuscript.
Stage 1 — Scope the paper before writing it
The highest-leverage hour in any manuscript happens before the first paragraph: deciding, in writing, what the paper claims. Strong teams open a structured project — not a blank document — that states the research question, the hypotheses or aims, the intended venue type, and explicitly, what is out of scope. Scope creep is the leading cause of the eleven-month “almost done” manuscript, and it thrives when the paper’s boundaries live in nobody’s head in particular.
This is also the moment to assign structural ownership. Not “everyone edits everything,” but a named owner per section, a designated reviewing author (usually the PI or senior author), and one person who owns the reference library. Ownership is what turns a document into a project.
Stage 2 — Draft into a structure, not onto a page
Papers have load-bearing skeletons: IMRaD for empirical work, PRISMA-shaped sections for systematic reviews, aims-significance-approach for proposals. Starting from a template that seeds the expected sections does two things. It converts the intimidating blank page into a set of small, answerable prompts, and it lets co-authors draft in parallel — methods can be written the week the protocol is finalized, months before results exist.
The practical rule: any section that can be written early, is. Methods, the data statement, author contributions, and half the introduction rarely depend on results. Teams that draft sequentially are borrowing deadline pressure from the future at a terrible interest rate.
Stage 3 — Treat references as data, not decoration
The bibliography is the part of the paper most likely to be assembled last and checked least, which is exactly backwards: it is the part external readers can audit most easily. A structured workflow treats references like a dataset with an owner and a quality bar — every entry resolves to a real identifier (DOI where one exists), metadata matches the actual work, preprints are flagged so published versions can replace them, and duplicates are merged before they fork into inconsistent citations.
Do this continuously, not terminally. A reference verified when it enters the draft costs seconds; four hundred references “verified” the night before submission cost a night — and in practice, they simply do not get verified, which is how the fabricated- and broken-reference problem reached the levels the field is now measuring.
Stage 4 — Make co-authoring a review workflow, not a merge problem
The single biggest upgrade for most teams is moving from circulating copies to one living manuscript. Attachment-based co-authoring forces someone to be the human merge tool, and every merge is an opportunity to lose an edit silently. One shared document with real roles — authors who write, reviewers who comment and approve, readers who observe — eliminates the entire class of problem.
Within that shared document, the teams that move fastest converge on the same etiquette:
- Suggestions over silent edits in sections you do not own — the section owner accepts or declines, so intent is never overwritten.
- Comments attached to the text they concern, not in a parallel email thread that detaches from the draft within a day.
- Explicit review gates: a section is submitted for review, then approved — like a pull request, so senior sign-off is a recorded state rather than a vague recollection.
Stage 5 — Validate before reviewers do
Every manuscript gets validated eventually. The only question is whether that happens pre-submission, in private and cheaply — or in review, at the cost of a rejection or a bruising major revision. A pre-submission validation pass should check, at minimum: that every reference resolves and matches its metadata; that cited sources still support the sentences citing them (claims drift during editing); that statistics are internally consistent between abstract, text, and tables; and that figures and tables are all referenced and numbered correctly.
This is checklist work, which is precisely why humans skip it and software should not. Automated checks that re-run on every edit turn validation from a dreaded phase into a background property — the manuscript is simply always in a checkable state, the way a healthy codebase is always buildable.
Stage 6 — Assemble the submission package once, generate it thereafter
A journal submission is more than a manuscript: it is a formatted main document, separated figures, a reference list in the journal’s exact style, a cover letter, declarations, and often an anonymized variant. Teams that treat this as a manual assembly job pay for it at every journal transfer — and transfers are the norm, not the exception.
The structured alternative is to keep the manuscript as the single source of truth and generate the package: export to DOCX, PDF, or LaTeX with the target journal’s citation style applied mechanically, figures bundled at the required resolution, and the anonymized version produced from the same source. When the paper is transferred from one journal to another, reformatting becomes a settings change instead of a lost weekend.
Stage 7 — Version the revisions like releases
The manuscript’s life does not end at submission; it forks. There is the version reviewers saw, the revision responding to them, and — months later — the version that must be reconciled with proofs. Name these versions deliberately: submitted-v1, R1-response, accepted. A named version is a commitment you can diff against, which makes the response-to-reviewers document almost mechanical to write: the diff between submitted-v1 and R1 is the list of changes, with nothing forgotten and nothing overstated.
The workflow in one line: scope → structured draft → verified references → reviewed co-authoring → automated validation → generated package → named revisions.
Making it stick
A workflow only survives if it is lighter than the chaos it replaces. Start with the two stages that pay off immediately — one living manuscript instead of attachments, and continuous reference verification — and add review gates and named versions on the next paper. Write the stages into the lab handbook with owners attached, and onboard new students into the workflow rather than around it.
We built Dissertatio so that this entire path — structured projects, role-based co-authoring, DOI-resolved references, always-on validation, journal-formatted export, and named versions — lives in one workspace instead of seven tools. But the workflow is the point, and it is portable. Teams that adopt the structure publish with less friction whatever they write in; teams that adopt the structure in a workspace built for it stop thinking about the process entirely, which is where the good science gets done.
Written by the Dissertatio Team — the people building the collaborative research-paper platform. Questions or disagreements? We read every reply: hello@hashtagai.io.