Write a procedure from the reader's starting point to a checkable result
Write a procedure with clear prerequisites, actions, exception paths and completion checks, using an original fictional paper-register task.
About 6 min read · Allow extra time for the practical checks
State what the reader needs before starting, give the actions in the order they can perform them, and explain how they can recognise completion. A useful procedure connects an actual starting state to an observable result. “Complete the process correctly” supplies neither the actions nor a way to check them.
Follow the documentation required for your project. This guide concerns writing ordinary instructions from a verified task record. It is not a laboratory protocol, an account of an experiment already completed, or a substitute for authorised safety and operating instructions.
Establish the reader’s actual starting point
Name the task and its boundary. Is the reader locating an existing item, preparing a file or recording a completed action? Identify the materials, access and information they need. State a prerequisite before the step that depends on it.
Work from the current artefact or process you are documenting. Check labels, locations and available actions rather than composing a plausible sequence from memory. If you cannot confirm a step, keep it unresolved in your draft until you can check it. Do not invent an interface control or access permission to make the sequence look complete.
Google’s procedure-writing guidance relates an instruction’s context, action and expected result. Use that relationship to check whether the reader can perform your particular task. Its house style is not a requirement for every academic project, and its product examples do not establish what exists in your own prototype.
Test an original fictional paper-register task
The materials, labels and procedure below are entirely invented teaching material. They describe no real collection, institution or software feature.
Imagine a capstone documentation exercise with a paper sample register and a folder of sample description sheets. The fictional materials have these properties:
- Each sample has one register row with a unique sample name and one sheet code.
- The folder has dividers labelled with those same codes.
- The task is to locate the description sheet for a named sample and confirm that its printed code matches the register.
- Some sheets may be absent. The record gives no authority to substitute a different sheet or alter the register.
The reader starts with the sample name, the current register and the folder. “Find the sample information” is too vague: it hides the register-to-code-to-divider relationship and says nothing about a missing or mismatched sheet.
A draft procedure based only on this fictional record could read:
- In the register, locate the row for the supplied sample name. Read the sheet code in that row. If there is no matching row, stop and report that the register does not identify a sheet for that name.
- In the folder, locate the divider labelled with that sheet code. If the divider is absent, stop and report the missing code.
- At that divider, locate the description sheet and compare its printed code with the code from the register. If the sheet is absent or the codes differ, report the discrepancy; do not choose a nearby sheet as a replacement.
- Finish when you have a description sheet whose printed code matches the supplied sample’s register entry. The match confirms this task’s locating check; it does not establish that the sheet’s contents are accurate or current.
This sequence is an original teaching example, not tested operating documentation. Its exception paths follow the supplied fictional limits. For a real project, use the actual authorised reporting route rather than leaving “report” unexplained. Test the written sequence with the real materials before calling it ready for use.
Check what each step asks the reader to do
A step should identify an action the reader can take from the state reached so far. Include enough context to distinguish the relevant item, particularly when several things have similar names. A long step may contain a natural small group of actions, but it should not conceal an unrelated task or a prerequisite the reader has not completed.
| Question about the fictional instructions | What the wording supplies | Gap it avoids |
|---|---|---|
| What identifies the starting row? | The supplied sample name | Asking the reader to guess which row matters |
| What connects register and folder? | The same sheet code | Assuming the sample name also labels the divider |
| What happens when the expected item is missing? | Stop and report the discrepancy | Quietly substituting a nearby item |
| What counts as task completion? | A sheet code that matches the relevant register entry | Treating any retrieved sheet as success |
| What does the result not prove? | Accuracy and currency of the sheet remain separate | Calling a locating check a content validation |
Avoid unhelpful descriptions such as “simply” or “obviously” when the reader needs a concrete instruction. Explain the location or decision instead. Use the names found on the actual materials consistently; a polished synonym can become confusing if the reader is trying to match a printed label.
Distinguish an expected result from a promised outcome
An expected result helps the reader judge whether a step reached the intended state. It should be something they can inspect at that point. In the fictional task, matching codes provide that check. “The collection is now reliable” would be a much broader conclusion unsupported by the locating procedure.
Include a decision or recovery route where a predictable difference changes what the reader should do. Follow the real process’s authority limits. Do not invent permission to overwrite records, skip a required review or repeat an action that could create a second submission.
If important branches make the instructions difficult to follow, consider whether the task needs separate procedures or a clearer starting choice. Numbering alone does not turn a confusing description into a usable sequence.
Read through the task from the stated start
Check the draft against the artefact or process, including the ordinary exception paths you have documented. Record the version checked. A writer who already knows the task may unconsciously supply missing knowledge; an appropriate reader check can reveal that gap, subject to your project’s requirements and permissions. Do not claim such a check occurred unless it did.
The capstone scope guide helps define the documentation deliverable and its limits. The laboratory Methods guide addresses the different job of reporting what an experiment’s records show actually happened. A procedure tells a reader what to do; a Methods account reports completed work.
Before finalising, verify the prerequisites, exact labels, order, exception routes and completion check. Then make the title describe the task the procedure actually completes. The reader should be able to tell when to start, what to do next, when to stop and which result they have established.
