A customer instruction can describe the right action and still leave the reader uncertain. “You should add your reference number” might mean the number is essential, merely helpful or expected to appear automatically. That ambiguity matters when someone is trying to complete a form, prepare a document or choose the next step in a service.
Clear instructional copy separates requirements, recommendations and optional actions. It also distinguishes what a person must do from what a system is expected to do. This is an editing problem before it is a formatting problem: a bold label cannot rescue a sentence whose underlying rule has never been confirmed.
Find the real rule before choosing the wording
Start by asking the person responsible for the process what happens if the reader does not complete the action. Can the task continue? Does it produce a different result? Does someone need to intervene? The answers help establish whether the action is required, recommended or optional. Do not infer a requirement just because an older page presents it confidently.
For example, a reference number might be essential for retrieving an existing request but unnecessary when making a general inquiry. Those are different situations, not competing ways to phrase one instruction. Record the relevant condition before writing. “For questions about an existing request, include its reference number” is more useful than an unconditional demand that some readers cannot satisfy.
If the operational answer is unknown, keep the wording provisional. Changing “should” to “must” without checking the process can create a false obligation. A writer can clarify a confirmed policy; writing alone cannot determine what the business actually requires. Mark the question for its owner rather than presenting uncertainty as a finished instruction.
Separate actions from expected outcomes
Read each sentence and identify its actor. Is the reader being told to do something, or is the page describing what will happen afterward? “The confirmation should appear” is uncertain in a different way from “You should confirm the address.” The first concerns an outcome; the second concerns an action.
Google’s guidance on prescriptive documentation recommends distinguishing required and optional actions, expected and possible outcomes, and actual and recommended states. It gives writers a useful diagnostic question: which of those meanings does this sentence need to convey? Choose language that answers that question instead of relying on one flexible auxiliary verb.
For an expected outcome, describe the observed behavior accurately: “A confirmation appears after you submit the form.” If the outcome only sometimes occurs, explain the condition or possibility. Avoid turning a likely result into a guarantee. If the system’s behavior has not been checked, ask for verification before describing it as certain.
Put important conditions before the action
A conditional instruction is easiest to interpret when readers encounter the condition before deciding what to do. Consider an illustrative sentence: “Upload the previous version if you are requesting a revision.” Readers handling a different task reach the action before discovering that it does not apply to them.
Reversing the order makes the branch clearer: “If you are requesting a revision, upload the previous version.” The condition establishes relevance first. This is particularly useful in instructions shared by several kinds of customers, where a single list can otherwise make every step appear compulsory for everyone.
Avoid packing several branches into one sentence. If new customers, returning customers and account administrators need different actions, separate those paths with descriptive subheadings or a short decision list. The goal is not to multiply words. It is to keep readers from combining requirements that belong to different situations.
Make optional steps visibly optional
Optional actions should not look like barriers to completing the main task. Label them clearly and explain their purpose when it is not obvious. “Optional: Add a project name to help you recognize this request later” states both the choice and its benefit without implying that the request will fail without it.
Do not label an action optional merely because it is technically possible to skip it. If skipping the step changes the service, delays processing or removes a feature the reader expects, explain that consequence. A meaningful choice requires enough information to understand the trade-off. Confirm that consequence with the process owner rather than guessing.
Keep optional enhancements separate from prerequisites. Someone should not discover after submission that a supposedly optional document was necessary for the version of the service they selected. Where a condition changes the requirement, place that condition beside the instruction and check it against the surrounding form labels.
Use recommendations without disguising them as rules
A recommendation gives readers a preferred approach while preserving their ability to choose another valid option. Explain why the preferred approach helps when that information supports the decision. “We recommend using a descriptive file name so the reviewer can identify the document” is clearer than presenting a naming preference as a universal rule.
Be careful with the reason. Do not claim that a recommended format is faster, safer or more accurate unless that claim is supported in the relevant context. You can often describe a direct practical purpose without promising a measured improvement. Recognizable file names, for example, help distinguish documents; they do not establish a quantified productivity result.
Where the recommendation comes from an external standard or authority, identify it and link to the applicable source. Where it is simply the team’s preferred workflow, say so. Readers should be able to tell the difference between a documented requirement and advice offered to make collaboration easier.
Test the wording with a worked example
Choose a realistic but explicitly fictional scenario and follow the instructions from start to finish. List the information the reader has at each stage. Check whether any sentence asks for information they have not yet received or describes an outcome before the action that produces it.
A worked example of a process can reveal missing conditions that a general explanation conceals. For this review, try both the main route and one legitimate alternative. If the optional path prevents completion, either the label is wrong or the process description is incomplete.
Ask a reviewer three questions: Which actions are compulsory? Which can be skipped? What happens after the final action? Compare their answers with the confirmed process. If they disagree, investigate the wording before adding more emphasis. Extra bold text can make an incorrect interpretation more prominent rather than more accurate.
Check the surrounding interface as well
Instructions rarely stand alone. A paragraph might say an attachment is optional while the form marks the field as required. A button might imply that information is saved even though it is only previewed. Compare the article with the actual labels and behavior that readers encounter at the time of review.
Record discrepancies instead of silently rewriting one surface to match another. The interface may be wrong, the article may be outdated or the process may have changed. Resolve the factual question with the responsible owner. Do not use an editorial revision to invent new behavior or to alter a service commitment.
Finally, keep the confirmed distinctions in a small review checklist. Check conditions, requirements, optional actions and outcomes whenever the process changes. Good instructional writing does not make every sentence sound forceful. It gives each sentence exactly the level of obligation and certainty that the underlying task supports.
Illustrative photo by Glenn Carstens-Peters on Unsplash, used under the Unsplash License.