How to write and publish a scientific paper
Organize the process, focus your goals, and order your writing
Writing your first scientific paper for publication can be daunting. In this post, I go through my general process for what to consider in each section, pitfalls to avoid, and how to handle the review process.
This all assumes you’ve got the bulk of the results done. It’s normal that as you’re writing, you come up with new experiments to prove out a point. The manuscript evolves.
New project, new document. Whenever a new project is taking shape, I create a blank document with headings for abstract, methods, results, and discussion. As the project evolves, I keep adding to this outline. Interesting papers get a quick summary in the discussion for later. Ideas for experiments and figures get sketched in the methods and results. Inclusion/exclusion criteria in the methods. Very fast and loose, but something you can share with co-authors to update on project status.
Identify your building blocks. For every study, there are probably only 2-4 key clinical studies you’re directly building off. Print out those papers and really study them. Those should be referenced in the introduction as part of your motivation and in the first two paragraphs of your discussion to show tie in. Everything else is just a distraction that probably deserves mention at best. Discuss these papers with your senior authors.
Write in order
Start by drafting the abstract. This will define the general trajectory: research question, basic methods, highlighted result, conclusion. The actual paper of course has many details, and may include experiments and results not mentioned in the abstract. As you start out, much of the abstract is unknown and vague but still you should try to articulate in broad strokes what the paper will set out to accomplish, how you intend to do it, and even speculate about what you expect to find. This abstract will evolve as the rest of the manuscript does. At this point, it should be enough that anyone coming to the manuscript later – coauthor or yourself – can quickly come up to speed on the project.
Finish by polishing the abstract. You’ll return to this abstract time and again, each time making sure it is in line with the rest of the paper.
Follow the reader’s eyes. Always keep your reader in mind. The first thing they read is the title and abstract, so those need to be the most polished pieces. Between drafting the abstract and its final touches, write in the order that they will read: right after reading the abstract, most people skim the figures and tables. From there, the methods, results, and discussion. For people familiar with a field, the conclusion and introduction are of lesser importance. Conclusions are often redundant and low quality summaries, introductions are often filled with history you already know, and both are of less importance than the abstract, methods, and results.
- abstract (draft)
- figures and tables
- methods, results, discussion
- conclusions and introduction
- abstract (polish) and title
Title
Put your main conclusion in the title. This is truly the first thing anyone sees, so make it count. If they remember nothing from your paper, they at least know the main finding.
- Bad: “The effect of Tylenol on headache symptoms”
- Good: “Tylenol decreases headache symptoms”
Title: Subtitle. Take the liberty of breaking your title up to squeeze in more information. You could use the subtitle to describe the type of study.
- Good: “Tylenol decreases headache symptoms”
- Better: “Tylenol decreases headache symptoms: A randomized controlled trial”
Avoid technical jargon. Try to avoid acronyms where possible, unless it’s truly understood through the vast majority of your readership. You want a wide reader catchment.
Gut check. After reading just your title, reviewers will already have a gut feeling of whether they are interested in a paper, and maybe even a bias to accept/reject.
Abstract
It should stand alone. Give some context, state the objective, summarize the basic methods, relate the most important results, and draw conclusions. Don’t speculate. Don’t be vacuous and hint at what the article contains. This abstract should contain the most juicy pieces without requiring the casual reader to have to fetch the full document.
Interested? The abstract can either solidify or dissolve the reviewer’s interest. By the end, a reviewer might already lean toward rejecting or requesting re-submission with further details.
Introduction
Remember your readers. Your readers are not students like yourself. They have been practicing science and performing surgery since you were in diapers. Don’t start at square one. Imagine as a graduate science major reading a paper where the intro sentence talks about how “addition and subtraction are common processes in mathematics” – you’d roll your eyes and skim right past it. A wasted sentence. Don’t start your neurosurgery article telling the readers that cranioplasty is putting back together the skull. Don’t start your internal medicine paper telling the reader how diabetes involves the pancreatic islet cells. Jump right into the meat with your first two sentences.
Don’t discuss. This is the introduction, not the discussion. Don’t be exhaustive and cite everything. Just cite a few (2-3) major studies that you’re going to springboard off. The discussion later can be a more exhaustive literature review. Similarly, leave the conclusion and results for the conclusion and results sections.
Too many citations. The intro should be very basic and merely introduce the topic. You should even get away with making basic statements that don’t need citation. You don’t want to overwhelm the reader with references they need to screen.
Why should we care? You need to quickly justify the importance of your project. How many people are affected? How bad is the disease on quality of life? Has there been some recent change in methods or studies you are exploiting?
Give perspective. How has this area evolved? What were some major changes in the past decade? Don’t go back more than a decade though – that’s for a history review, not a clinical article.
Two paragraphs. That’s all you need. The first paragraph introduces the problem and some perspective on the past decade. The second paragraph is even shorter, maybe two-three sentences, where you clearly state the clinical questions that form the goal of this present study. Sometimes you can insert a paragraph between these giving a review 2-3 studies you’re comparing against or building from.
Don’t oversell. Avoid cliche terms like “novel”, “unique”, or “first ever”. It’s all been done before in some form or fashion. You don’t want some tenured professor who’s seen it all to pull a muscle after rolling her eyes.
Methods
Write for a knowledgeable reader. Your audience should be familiar with your research area. They will likely have done similar projects, worked with similar substances, done the procedure themselves, used the same statistical tools. This reader should be able to reproduce your experiments.
Provide details. You can almost never have too much. This goes back to reproducibility: any constants, thresholds, or tuning parameters must be included. Every inclusion/exclusion decision you made. How long you waited to check something. If it’s a very new procedure you’re proposing with important details you want people to reproduce, then consider submitting a supplemental methods document.
Results
Only include the key results. You don’t need to detail every experiment you did. What you include needs to follow a logical progression and build toward clear conclusions. You don’t just want a catalog of things you tried. If you have more you think might be interesting to others, ie. inconclusive experiments others could build off, consider supplementary materials.
Supplementary materials. Any data that you want to share but don’t want to bog down the manuscript. Others may pick up from where you left off.
Use subheadings to group. Organize your results. This also helps later because you can organize your discussion around those exact subheadings.
Clearly address your goals. Keep going back and re-reading the abstract and intro. Make sure everything is inline. Make sure your abstract doesn’t overstate your actual results.
Keep a consistent order. The organization of your results should be mirror your abstract and methods. If you stray from this symmetric structure, you risk muddling the message.
Figures & Tables
Use color sparingly. Use it to emphasize key portions of a figure or graph; not everything has to be in awesome colors and shading. Not everyone prints out on a color printer. Shading can turn out crappy on a bad printer. For graphs, use different line styles that will show up on black and white printers.
Include scale. Every graph needs x/y-axis labels and units. Color intensity needs a labeled bar. Run your figures by someone completely unfamiliar with the project to see if they understand.
Two sentence captions: what it is, what it means. First sentence describes what you’re looking at, second sentence tells you what you should take away. If you use several figures of the same style, your first caption can include some extra details to familiarize the reader with symbols/layout, but then subsequent captions can omit this.
Tables report data, figures show trends. What type of information are you trying to communicate? Use the appropriate tool.
Discussion
Talk to the audience. Here is where you switch voice a little. You’ve just laid out all the facts. Now you get to take a deep breath and help the reader make sense of it all.
One intro paragraph. Begin the discussion with one paragraph contextualizing and summarizing the results. Very briefly connect your results with one or two other references.
Nothing new. Do not introduce any new results. You should make summary references to the results already documented and draw connections.
Compare your result with published results. Make connections. Are your findings in line with those of other groups? Did you come up with wildly different results? How did your work specifically extend that of others?
Address differences. Reference papers with different conclusions. As long as you were careful in your methods, it’s okay. It is what it is. Someone else may come later and figure out why there is a difference, but go ahead and take a crack at what you think explains the situation.
Make notes throughout your project. Every time you read a relevant paper, make a 2-3 sentence note on it. I record these in the tentative “Discussion” section of my developing manuscript, even before I have results. A good body of these will start to take form and it’ll be easy later to string these bullet points together into sentences and paragraphs.
What do you suggest? You are now the expert. Let your voice come through. What do you think is the best way of handling the topic? What do you suggest future studies look into? You have freedom here to vent a little. If it’s a systematic review and you found the literature a mess, tactfully suggest ways future studies can be more consistent. After all your experimental work, did you realize you screwed up and future studies should do it differently? Suggesting clear lines of future work is a great way to inspire others to follow the trail. Nothing is ever done and done. You shouldn’t worry if it’s something you yourself plan to do – getting scooped is rare in practice, and you already have a massive advantage with just having the present manuscript out.
Conclusions
What did you contribute? How did you advance the field? Be very specific but brief. Rank order your contributions, briefly state them, and don’t feel like you need to rehash every result.
Avoid numbers. The abstract is where you have the quantitative details. The conclusion is just to summarize the basic trends.
Suggestions? If there is one or two important suggestions buried in your discussion, give one last shout out. Be brief; your paper has all the details. Avoid the pithy ‘future work is needed’ – that much should always be obvious. Stating this adds zero value and eats printer ink.
Acknowledgments
While not everyone deserves a co-author spot, you have the liberty to show your appreciation with a small mention. Did someone help review your stats? Did someone do a lot of specimen preparation early in the project? Anyone who helped conduct experiments but may not have been justified a co-author spot.
References
Software. Mendeley, EndNote, Zotero – lots of options, but often it’s best to use what everyone else in your group is using. At any given time, I’m often using each of them for different projects. They all have pros and cons. I prefer Mendeley over EndNote over Zotero. EndNote has given me many problems when upgrading Word and/or EndNote.
Don’t futz around. While writing, don’t get bogged down searching and including references as you go. Simply cite with name/year and keep typing (Smith2002, Johnson2010). While drafting – right up until submission – I keep references in LastNameYear style for easier reading.
Show some judgment. Too many references means you’re unfocused. Don’t go overboard trying to cite everything that’s ever been done and is loosely connected. Focus on the few papers you were most impressed with. For a review article you need to extend a wider net, but for a research article you can show judgment. I’ve never had a reviewer kick back my papers because I didn’t cite something. They may make suggestions, but never is that a make it or break it.
Too few and you haven’t done homework. Nearly everything’s been done under the sun. You should easily be able to find a few key papers you’re building from.
Look at other papers to judge count. If the key papers you’re extending have ~20 citations, then aim for that. If yours turns out to have 40+, then maybe you need to show some judgment.
When stuck
### When I know I need to come back to something, this is what I drop in the text. It’s an unique tag that is easily searchable. Keep moving forward, don’t lose momentum. One of my biggest weaknesses is that I agonize over text, getting bogged laying down each sentence in final form. I’ve learned to relax more and just get it all out on paper by sprinkling these in wherever I know I need to come back later. Like an embedded TODO list.
Copy/paste. When I’m a little unsure about how to present something, my typical trick is to look at 3-5 example papers and pick the one or two I like the most. Often I will literally copy/paste from another article, and then go sentence by sentence using the same structure but rewriting completely using my own data. In the end there is zero plagiarism but you borrowed a structure to get started. As I continue revisiting and revising, eventually the text becomes all my own and turns out completely unique from the initial copy/paste.
Responding to reviewers
Respond quickly. Reviewers fatigue and their attention wains. Best to get it back to them quick while it’s still fresh in their head.
Create a response document. Start by pasting the reviews verbatim. I tend to reformat them in bold/italic with each paragraph prefixed by “>”. I then embed my responses in plain text after each reviewer’s point. This way, if you have to paste your whole response into a plain text form, the difference between reviewers and your comments will still be clear.
Triage. Make a separate checklist for you and co-authors, ordered by importance. Keep going down that list until you judge items not important. Then justify everything below that line.
Start by thanking the reviewer. Highlight any specific ideas you appreciated. Thank them for their time.
Never argue. Guarantees failure. Be tactful in your responses. Reviewers may be quick/sloppy but they are never stupid and they are always “right”.
Address everything. You might get away with glossing over minor suggestions, but best to acknowledge and give your thoughts. Better to say you considered something and, while you didn’t do exactly what is suggested, you did something similar.
Michael Ernst (University of Washington) on “How to write a technical paper”