How do I explain exceptions without burying the normal instructions?
Quick answer
Write the normal instruction first, in the order most readers need it. Put an exception inline only when it is brief and closely tied to that step; move it to a separate note or section when it needs explanation, applies across several steps, or would interrupt the main route. In either place, state who the exception affects, what triggers it, and what to do instead.
The question, the details, the next step.
I have a set of instructions that applies to most readers, but a few people need to do something different. How do I explain that without making everyone work through caveats?
Give the usual route a clear, uninterrupted path. Start with the action most readers should take, and add an exception only where readers need it to choose or complete that action. If a caveat appears before the standard instruction, readers may have to hold it in mind before they know whether it applies.
For each exception, make three things explicit: who it applies to, the condition that triggers it, and the alternative action. Avoid vague signals such as “in some cases” unless you identify those cases. For example, as a writing illustration: “Usually, submit the form online. If you do not have online access, use the paper form instead.” The second sentence identifies the condition and the alternative without making every reader consider a long list of possibilities.
How do I decide whether the exception belongs in that step or in a separate section?
Use an inline exception when it is short, affects only that particular step, and can be understood without explaining several other rules. Keep it close to the instruction it changes, so readers do not have to guess what the caveat modifies.
Use a separate section when the exception takes more than a sentence or two, changes several steps, needs its own sequence, or applies to a clearly identifiable group throughout the document. Give that section a descriptive heading, such as “If you are using the paper form,” rather than a vague heading like “Exceptions.” Then point to it at the relevant step: “If you are using the paper form, follow the separate instructions below.”
A practical test is to read the normal instructions with the exception removed. If they remain complete and safe to follow, the exception may be separate. If removing it would leave an affected reader doing the wrong thing, keep a brief pointer or condition at the point of action.
What if an exception affects only one step, but the explanation is too long to fit neatly inline?
Keep the decision point near the step and move the longer explanation beside it or to a clearly named subsection. The short inline cue should tell affected readers that a different route exists; the longer text should explain what to do. Do not leave readers with a bare “see exceptions” reference if they cannot tell whether it applies to them.
For example, suppose a fictional instruction says: “Step 2: Choose a delivery option.” A compact version might read:
“Step 2: Choose a delivery option. If your order is being collected by a representative, see ‘Collection by a representative’ below before choosing.”
The subsection can then give the specific alternative steps. This is only a layout example: replace the condition and action with the ones that are actually true for your process. Check that the subsection heading uses the same words as the pointer, so readers can locate it quickly.
Can you give me a quick method for reviewing a draft so I catch confusing exceptions?
Review the document in two passes. First, read only the standard route: headings and main instructions. Ask whether a typical reader can follow the sequence without detours. Then scan for words that often introduce exceptions—“if,” “unless,” “except,” “only,” and “otherwise”—and check each one.
For every exception, ask: Is the affected reader identifiable? Is the trigger concrete? Is the alternative action stated? Is the exception next to the decision it changes, or clearly signposted elsewhere? Finally, try reading from the perspective of someone who meets the condition. Can they find their route without guessing or combining scattered caveats?
A useful copyable pattern is: “Usually, [standard action]. If [specific condition], [different action].” For a separate section, use: “[At the relevant step:] If [condition], see ‘[descriptive heading]’ for the different route.” Treat these as drafting patterns, not substitutes for checking that the instructions match the real process.
A practical checklist
State the usual action before introducing a less common route.
Name the group or condition that makes the exception apply.
Say exactly what the affected reader should do instead.
Keep a short, step-specific exception beside the instruction it changes.
Move longer or multi-step exceptions to a descriptive, easy-to-find section.
Add a clear pointer at each relevant decision point.
Read the standard route and the exception route separately to check both are understandable.
A few more useful answers
Should I label every exception “Important”?
No. Use a heading or visual emphasis when readers need to notice a distinct route, but make the label describe who or what it concerns. Repeating a general warning label can make the actual difference harder to spot.
What if there are several exceptions?
Group related exceptions under headings readers can recognize, such as a condition or reader group. Keep a short pointer near each affected step, and avoid one catch-all section that forces readers to search through unrelated cases.
How can I tell whether an exception is too vague?
Check whether a reader can decide, from the wording, whether the condition applies and what action follows. If either answer depends on guessing, specify the trigger or clarify the alternative.