A clear instruction tells someone what to do. A clear conditional instruction also tells them whether that action applies to their situation. If the condition is vague, buried, or attached to the wrong action, readers may follow a step that was never meant for them.
Conditions and exceptions deserve their own editing pass in business procedures, customer guides, and team handbooks. The aim is not to make every sentence shorter. It is to make each decision visible: check this circumstance, choose the relevant path, and take the specified action. The workplace examples below are hypothetical illustrations, not descriptions of actual company policies or results.
Separate the condition from the action
Start by identifying the two parts of the instruction. The condition describes the situation that makes a step relevant. The action describes what the reader should do in that situation. “If the request includes a replacement item, record the original order number” contains both parts. The reader can check the request before entering anything.
Compare that wording with “Record the original order number for replacement requests where appropriate.” The action arrives before the reader knows whether it applies, and “where appropriate” leaves the decision undefined. Removing that phrase does not solve the underlying problem. The writer must know what makes the order number necessary.
Google’s guidance on writing for a global audience recommends presenting the circumstance before the instruction that depends on it. This gives readers a useful sequence: first determine applicability, then act.
Use that sequence as a practical default. “If you are updating an existing account, enter its account number” is easier to evaluate than an instruction that reveals the existing-account restriction at the end. Keep any prerequisite information nearby, including where readers can find the number they need.
Choose if or when deliberately
Use “if” to introduce a circumstance that may or may not apply. Use “when” when the instruction concerns a point in an expected sequence. In a hypothetical upload guide, “If the file exceeds the size limit, split it into smaller files” describes a possible branch. “When the upload finishes, check the confirmation message” describes the next stage.
The Microsoft style guide’s distinction between if and when associates “if” with conditions and “when” with timing or preparation. That distinction is useful when an instruction could otherwise make an optional event sound inevitable.
“When the reviewer requests changes, revise the summary” implies that a request is part of the expected process. “If the reviewer requests changes, revise the summary” leaves room for approval without revisions. Neither word should be chosen merely to vary the prose. Choose the one that matches the actual workflow.
A sentence may need both concepts, but not necessarily both words. Instead of “If approval arrives, when you have it, send the document,” write “After you receive approval, send the document.” If approval can be refused, explain the refusal path separately rather than embedding every possibility in the timing sentence.
Use conditions readers can actually check
Words such as “large,” “urgent,” “complete,” and “suitable” can conceal missing criteria. “If the attachment is large, use the transfer service” does not tell the reader how to decide. In a hypothetical procedure with a defined limit, “If the attachment is larger than 10 MB, use the transfer service” gives the reader a testable threshold.
Do not invent a threshold just to make the writing sound precise. Confirm the actual limit with the process owner. If the software displays the relevant information, identify that location: “Check the file size in the attachment details.” Precision requires an accurate rule and a practical way to apply it.
Boundaries also need attention. “Under 10 MB” and “over 10 MB” leave exactly 10 MB unassigned. If the intended rule permits files of that size, write “10 MB or smaller” for one path and “larger than 10 MB” for the other. Check dates, quantities, account statuses, and role names for similar gaps.
Use unless only when the exception stays simple
“Unless” can state a straightforward exception efficiently: “Send the weekly summary unless the project is paused.” The default action and the exception are both visible. However, the wording becomes harder to follow when the instruction already contains a negative or when the exception itself has several conditions.
Consider “Do not close the request unless it has not been returned for correction.” Readers must untangle two negatives, and the sentence does not establish whether other closure requirements exist. A clearer version might be “Close the request only after all required checks are complete. If the reviewer returns it for correction, keep it open until those corrections are approved.” That revision is appropriate only if it reflects the actual process.
Before replacing an “unless” sentence, write out the default and the exception separately. Confirm that the rewrite preserves both. “Send the summary unless the project is paused” is not equivalent to “Send the summary if the project is active” when the system also has a pending status. A smoother sentence must not silently change the rule.
Make combined conditions explicit
“If the report is approved and the recipient list is confirmed, send the update” requires both conditions. “If the report is approved or the recipient list is confirmed” permits sending when either condition is satisfied. Those small connecting words change the instruction, so check them against the intended decision rather than treating them as stylistic details.
When the sentence mixes “and” with “or,” unpack it. “Send the notice if the deadline changes or the location changes and the booking is confirmed” leaves the grouping unclear. Does the confirmation requirement apply to both kinds of change or only to location changes?
If confirmation applies to both, a clearer hypothetical version is: “First, check that the booking is confirmed. For a confirmed booking, send a notice if either the deadline or the location changes.” For more complicated branches, give each case a separate instruction. Do not ask readers to solve a miniature logic puzzle while completing the task.
State what happens outside the main path
A condition can be clear while the procedure remains incomplete. “If the record matches, continue” leaves an obvious question: what should someone do when it does not match? Depending on the real workflow, the alternative might be to correct an entry, contact a named team, or stop without submitting the form.
Explain the alternative when readers need it to proceed. Also distinguish “not applicable” from “unknown.” A reader who cannot determine whether a record matches should not automatically follow the mismatch path. If uncertainty is possible, provide a defined way to resolve it rather than inviting a guess.
Conditional does not mean optional. A step can be required whenever its condition is met. For example, “If you change the delivery address, confirm the revised address before submitting” does not make confirmation a personal preference. Keep that distinction consistent with your wording for required and optional instructions.
Test the instructions with contrasting cases
Before publishing, walk through one case where the condition applies, one where it does not, and one at any relevant boundary. For a size limit, test a smaller file, an equal-sized file, and a larger file. For an exception, test both the ordinary case and the excluded case.
Ask a reviewer to name the action for each case using only the written instructions. If they need an explanation from you, put the missing decision information into the document. The final test is simple: readers should know which path applies, what to do next, and where to turn when they cannot determine the answer.
Photo: Alvaro Reyes / Unsplash. Illustrative stock photograph.