Instructions Technical Writing Example: 7 STE Fixes

A technician is partway through a repair when an instruction makes them stop: “Make sure it's safe, remove the cover, and check the connection.” Which part of the equipment does “it” refer to? What makes it safe? Does the check happen before or after the cover comes off? When instructions bundle actions and bury conditions, readers have to interpret instead of follow.

Simplified Technical English (STE) isn't about making technical writing simplistic. It's a controlled way to make procedures easier to understand, translate, verify, and execute. Developed for aerospace maintenance communication, ASD-STE100 emphasizes controlled vocabulary and clear, direct instructions. Its first formal release appeared in 1986, and the current Issue 9 replaced earlier issues in 2025 (ASD-STE100's history and current status).

The examples below show a practical editing path: fix the language first, then improve structure, safety information, and organization. Each before-and-after pair makes a distinct decision visible, so you can apply the same checks to maintenance procedures, product manuals, and software help.

Table of Contents

• 1. ASD-STE100 Simplified Technical English procedural step writing
  • Change one sentence into one action
• 2. STE warnings, cautions, and notes in procedures
  • Keep warnings, cautions, and notes distinct
• 3. S1000D procedural data modules for task-based authoring
  • Write for reuse, then control changes
• 4. DITA task topics for step-by-step instructions
  • Match the structure to the task
• 5. ANSI Z535.6 product safety information in manuals
  • Check the hazard message, not just the signal word
• 6. Plain-language procedural instructions
  • Keep terminology consistent and test the sequence
• 7. Vendor style guide procedure conventions
  • Set a baseline for product-specific rules
• 7 Technical Instruction Writing Examples Compared
• Build a Repeatable STE Review Routine

1. ASD-STE100 Simplified Technical English procedural step writing

Consider a maintenance card that says, “Make sure the hydraulic system is depressurized before you start removing the actuator fitting.” The instruction contains a necessary condition, but the action and condition compete in one sentence. In a procedure, readers should be able to identify what to do and what must be true before they do it.

Before: Make sure the hydraulic system is depressurized before you start removing the actuator fitting.

After:

1. Make sure that the hydraulic system is depressurized.
2. Remove the actuator fitting.

The revision separates the prerequisite from the action. It also replaces the indirect phrase “before you start removing” with a direct instruction. The writer must still verify that depressurizing the system is the correct prerequisite for this task. STE editing improves clarity; it doesn't supply missing technical knowledge.

Change one sentence into one action

Now consider: “The technician should probably check the torque on the bolts after installation.” “Should probably” weakens the instruction, while “the technician” describes the actor instead of telling the reader what to do.

After: Check the torque of the bolts.

The imperative verb “Check” puts the required action first. “Probably” disappears because procedural instructions shouldn't make a required action sound optional. Before using the revised sentence, confirm that the task identifies which bolts and what torque value or acceptance criterion applies. A short instruction can still be incomplete if it leaves out information the technician needs.

Practical rule: Use one action per sentence, but don't remove conditions, identifiers, or acceptance criteria that make the action safe and testable.

ASD-STE100 began as an aerospace response to the challenge of helping aircraft-maintenance personnel understand English-language instructions, including readers with a basic command of English. Its development started under AECMA, with support from the Aerospace Industries Association of America and at the request of European airlines. That history explains why a procedural sentence in STE is more than ordinary prose made shorter: it's part of a controlled method for maintenance communication. For an overview of what Simplified Technical English is, start with the scope and purpose, then check each word and sentence against the official Issue 9 specification.

2. STE warnings, cautions, and notes in procedures

A warning at the end of a procedure can arrive too late. If a reader encounters a hazardous step before seeing the hazard, the safety information hasn't done its job. Put each safety message before the step it affects, and make the required action visible.

Before: Remove the connector. Be careful because the pins may be live.

After:

WARNING: Do not touch the connector pins. Electrical shock can cause injury.

1. Disconnect the connector.

The revised warning names what not to touch and states the consequence in a separate sentence. The step follows the warning, so the hazard is visible before the reader acts. The technical reviewer must still confirm that the warning matches the equipment and the applicable safety requirements. A writer shouldn't add or change hazard levels based on style preferences alone.

Keep warnings, cautions, and notes distinct

Use a warning for a hazard that can cause injury, a caution for a risk of equipment damage, and a note for useful information that isn't itself a hazard. For example:

• WARNING: Do not touch the connector pins. Electrical shock can cause injury.
• CAUTION: Do not use a metal tool on the seal surface. The seal can be damaged.
• NOTE: The bracket is installed with the arrow up.

A note can clarify orientation; it shouldn't carry a hazard that belongs in a warning or caution. Keep established wording consistent across related procedures, and have safety reviewers check signal words separately from general editing. The STE writing rules can help writers assess the language, but the organization's safety policy and applicable industry requirements determine how hazards must be classified and presented.

3. S1000D procedural data modules for task-based authoring

A procedure may appear in several publications. If editors copy and revise the same instructions in separate manuals, one version can drift from another. Structured authoring addresses this by treating a procedure as a reusable module, rather than a block of text tied to one document.

For example, a land-vehicle maintenance task might be organized around its preconditions, ordered steps, and post-task checks. A technical publication team can then manage that task as a discrete unit and reuse it where the same procedure applies. The exact requirements depend on the program, customer, configuration, and applicable S1000D rules, so confirm those requirements before building the module.

Write for reuse, then control changes

Keep each module focused on one task. Put the conditions that must be true before the task in the preconditions, and state any required result or verification after the actions. Write the steps in controlled, consistent language so that a module remains understandable when it appears in a different publication or translation.

Reuse makes review more important, not less. A change to a shared module can affect every publication that uses it, so assign clear reviewer roles and manage revisions through the program's change-control process. Before release, verify that the module applies to the intended equipment configuration and that its prerequisites, warnings, actions, and postconditions agree. Structured authoring helps teams organize and maintain procedures; it doesn't validate the engineering content for them.

4. DITA task topics for step-by-step instructions

A software setup instruction often mixes preparation, actions, and the result in a single paragraph. A DITA task topic gives writers a structure for separating those parts, so readers can find what they need before they begin.

Before: To connect the application, open settings, enter the server address, save the changes and check that the connection works.

After:

Task: Connect the application to the server

Prerequisites: You have the server address and permission to change the application settings.

1. Open Settings.
2. Enter the server address.
3. Save the changes.

Result: The application shows that it's connected to the server.

The revision gives the task a clear goal, states what the reader needs, separates actions into steps, and describes how to confirm success. If the application uses a different label or connection indicator, update the example to match the actual interface. Writers shouldn't guess at interface behavior.

Match the structure to the task

Keep each topic focused on one goal. Put conditions that must be met before the first step in prerequisites, and state the expected result where readers can check it. Write each step as a direct action, then test the procedure with someone who didn't write it. Watch for places where they hesitate or expect a different outcome.

DITA structure and controlled language can work together: the topic organizes the task, while STE-style rules guide the wording of each instruction. For examples of STE procedures and sentences, compare the wording as well as the layout. A well-structured topic can still contain vague actions, missing warnings, or unverified assumptions, so review its content as carefully as its markup.

5. ANSI Z535.6 product safety information in manuals

Safety text shouldn't be formatted as if it were ordinary procedure content. A product manual may need a reader to recognize a hazard quickly, understand its consequence, and take the correct precaution before continuing. ANSI Z535.6 provides a framework for presenting product safety information in manuals and instructions; teams must also check the current edition and the requirements that apply to their product and market.

Before: Do not service the unit unless it is safe. You could get hurt.

After:

WARNING: Disconnect the power source before you service the unit. Electric shock can cause injury.

The improved message identifies a specific precaution and a consequence. The phrase “unless it is safe” asks the reader to make an undefined judgment, while “you could get hurt” doesn't explain the hazard. The writer must confirm that disconnecting the power source is technically correct and sufficient for the service task. A clearer sentence can't substitute for a validated safety procedure.

Check the hazard message, not just the signal word

Use signal words consistently with the defined hazard levels in the applicable standard and organizational policy. Place the message before the instruction it qualifies, and coordinate the wording and presentation with product safety and legal reviewers before publication. Keep the safety message concise, but don't cut the detail needed to identify the hazard or precaution.

For manuals that also use STE-style steps, treat safety formatting and procedural language as related but separate review tasks. One review checks that the hazard information appears in the right form and location; another checks that actions are clear, ordered, and unambiguous. Confirm both before release.

6. Plain-language procedural instructions

A software help page says, “Utilize the configuration panel to modify parameters.” The reader has to translate formal wording into an action. Plain language makes that action more direct.

After: Use the settings panel to change options.

The new sentence replaces "utilize" with "use" and "modify parameters" with "change options." But the revision is only correct if the interface calls that screen "Settings" and "options" accurately describes what the reader can change. Plain language doesn't mean replacing technical terms that users need to recognize.

Keep terminology consistent and test the sequence

Plain language favors familiar words, active voice, short sentences, and logical order. For a task such as setting up an application, writers can first state what the user needs, list actions in the order they occur, and describe what successful completion looks like. Then ask a user to follow the instructions and note where they pause, misunderstand a term, or expect a different result.

A glossary helps writers use product names consistently, especially when several teams edit the same help system. STE and plain-language guidance overlap in their attention to clarity, but they serve different content needs. STE provides controlled rules and vocabulary for technical documentation; a general plain-language approach may suit public-facing or software content that doesn't need that same level of language control. Compare the actual needs of the readers and the risks of the task before choosing a method, and use Plain English versus STE to understand the distinction.

7. Vendor style guide procedure conventions

A developer guide tells users to “Click Save, then open the deployment menu and select the target environment.” That instruction contains several actions, and the UI labels may be hard to scan. Splitting the sequence gives each action its own place.

Before: Click Save, then open the deployment menu and select the target environment.

After:

1. Select Save.
2. Open the deployment menu.
3. Select the target environment.

The revision separates the actions and highlights the interface label. Before publication, check that Save matches the product interface exactly, including capitalization, and verify the name of the deployment menu. Don't bold a guessed label and treat it as confirmed.

Set a baseline for product-specific rules

Microsoft and Google publish style guidance that software documentation teams can use as a starting point. A team can adopt a published guide, then add its own glossary and rules for product terminology, UI labels, and task results. Consistency matters most when different writers describe the same action or interface element.

For global products, use a stable term for each feature and avoid switching between synonyms when the interface offers one exact label. Keep the expected result separate when readers need to confirm that a step worked. Then review the instructions with a user who can follow the process in the product, not just on the page. A style guide supports consistent wording, but testing reveals whether the procedure works for its intended audience.

7 Technical Instruction Writing Examples Compared

Build a Repeatable STE Review Routine

A reliable review begins with the task, not with sentence polishing. State what the reader must accomplish and what they should see, measure, or verify when the task is complete. If the expected result is unclear, writers can't reliably decide whether a procedure includes the right steps or ends at the right point.

Next, examine the sequence. Split compound instructions so that each sentence gives one action, and put prerequisites before the actions that depend on them. Replace weak or vague verbs with direct imperative verbs, name the equipment or interface instead of relying on unclear pronouns, and state conditions explicitly. Keep the actions in the order a reader needs to perform them.

Review safety information separately. Put each warning or caution before the step it applies to, state the hazard and consequence clearly, and confirm the message with the people responsible for technical and safety approval. Then check the vocabulary, sentence limits, and other applicable rules against ASD-STE100 Issue 9. A heuristic checker can flag possible issues during an early review, but it can't replace the specification, subject-matter expertise, or user testing.

A repeatable review can cover these questions:

• Task: Does the title describe one clear goal?
• Prerequisites: Does the reader know what must be true before starting?
• Actions: Does each sentence give one direct action, in the correct order?
• Safety: Are warnings and cautions visible before the affected steps?
• Verification: Does the procedure say how to confirm success?
• Language: Have you checked terminology and sentence rules against Issue 9?
• Validation: Has a qualified reviewer checked the technical content, and has a user tried the procedure?

Teams can use a free heuristic checker, such as the one offered by STE Guide, to flag likely wording and vocabulary issues before expert review. Treat its results as triage, not as an official conformity assessment. Apply the same review logic to maintenance procedures, product safety information, software help, and content sent for localization. The target isn't the fewest words. It's a procedure that tells the right reader what to do, under what conditions, and how to confirm the result.

STE Guide provides explanations of ASD-STE100 writing rules, worked examples, and a free heuristic checker for early review of technical instructions. Use its learning resources to practice separating actions, prerequisites, and safety messages, then visit STE Guide to explore the guidance and find the official specification.