Who is the reader?

You know your project better than anyone. That's exactly the problem. Steven Pinker calls it the curse of knowledge: once you know something, it's very hard to imagine not knowing it. So you skip steps, use your own abbreviations, and assume background the reader doesn't have.

Picture a real reader

Write for a smart colleague in a neighbouring field: someone who reads papers, but hasn't been in your lab, doesn't know your dataset, and doesn't share your shortcuts.

What that means in practice

• Define every abbreviation the first time, and use few of them.
• Explain why each step was done, not just what.
• Use the same word for the same thing throughout. If it's "participants" on page 2, don't switch to "subjects" on page 5; readers will wonder if they're different.
• Show, then tell: an example before the general rule.

Check it

Give a draft to someone outside your project. Ask them to mark every place they got lost or had to reread. Those marks are more valuable than any grammar check.

The venue matters too

A conference paper in your field can assume more than a broad journal like Nature or PLOS ONE. Read a few recent papers in your target venue to see the level they write at.

RememberYou're cursed by knowing too much. Write for a smart outsider, and test the draft on one.