A protocol another lab can actually reproduce comes down to seven things: a clear objective, exact materials, single-action steps, explicit parameters, the failure modes, versioning, and not starting from a blank page. Here's the step-by-step.
To write a good lab protocol: state the objective and scope, list every material and reagent with exact specs, write numbered single-action steps, make critical parameters (time, temperature, pH, concentration) explicit, record what tends to go wrong, and version every change with an author and a reason.
A protocol is only useful if someone else can run it and get your result. That's a higher bar than "write down what I did" — it means being specific where instinct says be brief, and honest about what fails. These seven steps are the difference between a method that travels and one that only works in the hands that wrote it. If you're not sure what a protocol is in the first place, start with what a lab protocol is.
Open with one or two sentences: what the procedure produces, and where it applies (and where it doesn't). A reader should know within seconds whether this protocol fits their experiment. Add safety and biosafety notes here, before any step — not buried halfway down.
Be specific to the point of pedantry: concentrations, grades, buffers, volumes, and catalog detail where the exact product matters. "5% BSA in TBST," not "blocking buffer." Note the instruments and their settings. A reader should be able to assemble everything before starting, with nothing improvised at the bench.
One action per step, in the order you actually do it. If a step contains the word "and," it's probably two steps. Number them so a colleague can say "I'm stuck on step 7" and you both know exactly where that is. Short imperative sentences beat dense paragraphs every time.
Time, temperature, pH, concentration, speed, volume — the values that change the result if you get them wrong. "Transfer for 90 minutes at 100 V, on ice" is reproducible; "transfer until done" is folklore. Flag which parameters are critical and which have tolerance, so the next person knows where the experiment is fragile.
This is the step that separates a protocol that travels from one that only works in your hands. Write down the failure modes you've hit and how you fixed them: the antibody lot that gave nonspecific bands, the step that only works below 8 °C, the reagent that suppressed the signal. These negative results are the highest-value part of the document.
A protocol is never finished. When you change a buffer or correct a step, record what changed, why, and who did it — as a new version, not a renamed file. Versioning ties every edit to a reason and an author, so the method gets more reproducible over time instead of fragmenting into divergent copies nobody reconciles.
Most of what you need already exists — in a paper's methods section, a lab notebook, or an old Word file. Bring that in and structure it, rather than retyping from scratch. On jnar, importing a method extracts the steps, reagents, and figures for you; then you add the parameters and failure modes you already know about.
Once a protocol exists, the work isn't done — it's begun. The methods that stay reproducible are the ones that keep absorbing fixes, which is why it's worth putting a protocol under version control from the start, and treating negative results as part of the record rather than something to hide.
State the objective and scope, list every material and reagent with exact concentrations and catalog detail, write numbered single-action steps in order, make the critical parameters (time, temperature, pH, concentration) explicit, record the failure modes and fixes, and version every change with an author and a reason. Then test it by having someone else follow it.
Specificity and honesty. Exact parameters instead of vague instructions, single-action steps in the right order, a complete materials list — and, crucially, a record of what tends to go wrong. A protocol that only documents the happy path forces the next lab to rediscover every dead end you already mapped.
As long as it needs to be precise, and no longer. Length isn't the goal — completeness is. A two-page protocol that names every reagent, parameter, and failure mode beats a ten-page one padded with prose. Use numbered steps and a materials table so density doesn't become a wall of text.
Yes. The conditions that failed, the reagent that suppressed your signal, the step that's temperature-sensitive — these negative results narrow the search space for everyone who reuses the method. Most protocols omit them, which is exactly why most methods are hard to reproduce. jnar keeps them as first-class, attributed data attached to the protocol.
Don't retype it. Import the methods document, paper, or notes you already have and let the structure — steps, reagents, figures — get extracted for you, then fill in the parameters and failure modes. The first conversion on jnar is free.
