What makes a procedure different
A procedure is a document meant to be followed while doing something else. The reader is not studying it; they are looking away from it to work, then glancing back to find their place. That changes how it should be written. It needs short steps, an obvious order, and no hidden assumptions, because the reader has no chance to ask the author what was meant.
This article covers general writing practice. For procedures that involve safety, regulated activities or quality systems, the content must follow the rules and approvals that apply in your industry and country. A well-written procedure supports qualified people; it does not replace training or judgment.
Start with purpose and scope
Open with a short statement of what the procedure achieves and when it applies. Then say what it does not cover. A reader should be able to tell in seconds whether they are in the right document. Add the following at the top, before the steps begin:
- Who the procedure is for, and what skills or authorisation are assumed.
- What is needed: tools, materials, access, documents and the state the system should be in.
- How long it typically takes, if that is useful for planning, described in general terms.
- Warnings that apply to the whole procedure.
Putting prerequisites first avoids the unpleasant discovery in step seven that a key item is missing.
One action per step
The core rule is that each step asks for a single action. Compare “Remove the cover, disconnect the cable and check the indicator” with three separate steps. The single sentence invites skipped actions, and gives no place for the reader to resume if interrupted.
- Number the steps in the order they must be done.
- Start each with a verb in the imperative: “Open”, “Select”, “Tighten”, “Record”.
- Name things exactly and consistently. If a part is called the “supply switch” in step two, do not call it the “power button” in step five.
- Give values, with units, instead of vague words. “Wait until the indicator is steady” is better than “wait a bit”, and “wait 30 seconds” is better still if time truly matters.
- Avoid leaving choices unexplained. If the reader must decide something, state the criteria.
Where several actions form a natural group, use headed sections, then numbered steps within each. Keep sequences of numbered steps to a manageable length; if a procedure runs to dozens of steps, consider splitting it into stages.
Say what the result should be
Many procedures fail not because a step is wrong but because the reader cannot tell whether it worked. After steps where it matters, state the expected outcome: a message that appears, a reading within a stated range, a sound or a position. Then say what to do if it does not happen, even if that is only “stop and contact the person responsible”. This turns the procedure into something self-checking, rather than a list of hopeful actions.
Checks that must not be skipped can be set apart as verification steps or as a short checklist at the end. This links closely to the idea of acceptance criteria: a clear statement of what counts as done.
Handle warnings with care
Put a warning before the step it concerns, not after, since the reader may already have acted. Make it specific: say what could go wrong and how to avoid it. Use warning formatting sparingly. If every second line is highlighted, readers stop noticing any of it. Distinguish levels where your organisation has conventions, and follow those conventions, since they may be set by company policy or applicable standards. Reading about hazard identification and the hierarchy of controls gives a sense of why warnings are the weakest form of protection and should not be the only one, but a procedure is still the place where the necessary warnings must appear clearly.
Keep the language plain
Short sentences, common words and a direct tone make procedures easier to follow, especially for people reading in a second language or under pressure. Prefer “use” to “utilise” and “check” to “verify the correctness of”. Plain language is a skill in its own right, and the general advice of technical writing applies: know the reader, say one thing at a time, and cut every word that does not help. Avoid unexplained abbreviations. Pictures, diagrams and labelled photographs can replace paragraphs of description when the task involves position or appearance, as long as they are clear and current.
Allow for variation without rambling
Real tasks have branches. Handle them in a way that keeps the main path clean.
- Use a short “If… then…” step at the point where the choice arises, and make the condition testable.
- Move rarely used branches and troubleshooting into a separate section after the main steps, with a pointer from the step where they might be needed.
- Do not bury exceptions in the middle of a long sentence.
If branching becomes complicated, a flow diagram may serve better than text, as discussed in guides to drawing engineering diagrams.
Test the procedure with someone new
Authors know too much to judge their own work. The only reliable test is to have someone who has not done the task follow the procedure exactly as written, while you watch and say nothing. Note each place they hesitate, ask a question or do something unexpected. Each is a flaw in the document, not in the reader. Fix them and test again.
Where the task carries real risk, do the trial in a controlled setting, with a qualified person present, and follow whatever approval the task needs.
Control and maintenance
A procedure that is out of date can do harm, so give it a version, a date and an owner. Update it whenever the system, tools or practice change. When the procedure changes, make sure old copies, particularly printed ones, are withdrawn. Where procedures are formally controlled, follow the change process that applies. People should be able to tell at a glance whether the copy in front of them is current.
Encourage users to report steps that were unclear or wrong. Their feedback is the cheapest quality check you will get, and it keeps the procedure aligned with how the work is actually done.
A short checklist
- Is the purpose and scope stated?
- Are prerequisites listed up front?
- Is there one action per step, in order, with exact names and values?
- Does each important step say how to tell it worked?
- Are warnings placed before the relevant step?
- Has someone new tried it and succeeded?
- Does it show a version, date and owner?