Verbs, tense, and mood

The verbs you choose shape how instructions feel to a reader. A precise, well-chosen verb makes a step feel achievable and clear. A vague or poorly matched verb creates ambiguity and slows readers down. This article covers verb selection, tense, mood, and sentence-level ordering as they apply to documentation.

Consistent verb form matters beyond readability, too. An answer engine or AI assistant extracting a step to answer a question relies on that step being phrased predictably — "Click Save" is trivial to lift out and cite correctly; a step phrased inconsistently in mood or tense from its neighbors is more likely to be paraphrased incorrectly or dropped.

Use Imperative Mood for Instructions

Imperative mood gives commands directly. It is the natural choice for procedural documentation because it is the clearest way to tell someone what to do.

Imperative mood is direct without being rude. It is the register that instructional content — recipe books, manuals, tutorials — has always used because it works.

See also: Imperative mood and active voice are related but distinct — imperative mood is about who the sentence commands, active voice is about whether the actor is named. For guidance on avoiding passive constructions elsewhere in an article (outside of direct instructions), see the Passive Voice section of the Voice and Tone guide.

Use Present Tense

Documentation describes how things work now. Write in present tense except in two specific situations: when describing a result that follows a step, and when providing historical context.

The exception for sequential results: when describing what happens after a specific step, present tense can feel grammatically awkward. "Click Submit. A confirmation email is sent" is correct but slightly stilted. "Click Submit. A confirmation email will be sent to your address" is acceptable in this specific context.

Choose Precise Verbs for UI Interactions

Different interface elements require different action verbs. Using the right verb for each element prevents ambiguity, especially for readers who are navigating with assistive technology or following instructions in an unfamiliar interface.

Avoid Weak Verbs

Weak verbs — particularly "do," "make," "get," and "perform" — create vague, wordy sentences that could almost always be rewritten with a stronger, more specific verb.

Order Conditions Before Actions

When a step only applies under certain circumstances, state the condition first, then the action. A reader scanning line by line should learn whether a step applies to them before being told to do it — not discover partway through a sentence that the instruction didn't apply at all.

This ordering also matters for troubleshooting content built around symptom-first structure ("If you see X...") — condition-first phrasing is what makes that pattern work consistently.

Negative Instructions and Prohibitions

Prohibitions need the same precision as positive instructions. State clearly what not to do, and — where it helps — why, so the instruction reads as guidance rather than an arbitrary restriction.

Contractions ("don't," "can't") are acceptable in prohibitions if your style guide otherwise permits a conversational register — but be consistent about it across the knowledge base rather than mixing "do not" and "don't" arbitrarily.

Tense in Non-Procedural Content

In conceptual and reference content, present tense is also the default. You are describing how things work, not how they worked or will work.

Release notes are the main exception. Release notes document changes that occurred at a specific point in time, so past tense is appropriate: "Fixed an issue where the export button was unresponsive." "Added support for CSV imports."

When writing conceptual content that involves a sequence — like explaining how a process unfolds — present tense still works: "When a user submits the form, the system validates the entries and creates a new record."

Verb Form in Headings

Headings and table-of-contents entries should use a consistent verb form throughout a knowledge base — either gerunds ("Configuring settings," "Managing users") or imperatives ("Configure settings," "Manage users"), not a mix of both. Mixing forms is a subtle inconsistency that readers may not consciously notice, but it disrupts the pattern recognition that lets them scan a table of contents quickly. Pick one form as a house standard and apply it everywhere, including in how-to guide titles.

Modal Verbs: When to Use Them

Modal verbs — can, could, may, might, must, should, will, would — require careful handling in documentation. Each carries a different implication about whether something is possible, recommended, required, or uncertain.

Avoid "might" and "could" in most documentation contexts — they imply more uncertainty than usually exists, and readers find them frustrating. If you genuinely do not know whether something will happen, say so plainly: "Processing time varies depending on the size of your file."

Be careful not to use "should" as a softer stand-in for "must." If skipping a step will cause a failure, an error, or data loss, that's a requirement — write "must," not "should." Reserve "should" for genuinely optional best practices where skipping it has no serious consequence.

Self-Audit Checklist

Before publishing, check every procedural sentence against these questions:

• Are instructions written in imperative mood, not passive or descriptive phrasing?
• Is present tense used throughout, except for sequential results or historical/release-note content?
• Does each UI element use its correct, specific verb (click, select, enter, drag, and so on)?
• Have weak verbs ("do," "make," "get," "perform") been replaced with specific ones?
• Does every conditional step state the condition before the action?
• Are prohibitions phrased directly, with a reason given where it helps?
• Do headings use one consistent verb form (all gerunds or all imperatives) across the knowledge base?
• Is every modal verb chosen deliberately — and does "should" actually mean recommended, not required?