Simplified Technical English (STE): Rules and Examples

Posted by
Anastasia in Technical Writing on 4/29/20225 min read

confused

There's a notion in technical writing connected with documentation created in English called Simplified Technical English. This is quite an interesting concept that definitely deserves the attention of the techcomm community. Let's start with a brief history of this term.

When Things Got Way Too Complex

pilots

It all started in the civil branch of the aircraft industry in the late 1970s. Being an extremely complex field, civil aircraft ended up with hardly readable user manuals. So unreadable, in fact, that people got seriously concerned.

When industry entry levels get too high, it decreases the flow of new people in there as only a few of them can get in. Things get stale, which is not good. Plus, you need to invest more to translate/interpret documents. It's also bad for the market — selling things people would hardly know how to use and repair. You can imagine what these user manuals were like that even the people inside the industry felt like they had to change.

Anyway, in the late 70s, European Airlines asked the European Association of Aerospace Industries to get involved and check the documentation readability. The American Aerospace Industries Association joined in the investigation and the conclusion was: this overcomplicated documentation had to stop! A project called Simplified English was developed to solve this issue. It launched in the year 1983. The collaboration was pretty fruitful, and a document called the AECMA Simplified English Guide was created.

In 2004 it changed its name to Simplified Technical English.

What is Simplified Technical English?

Simplified Technical English (ASD-STE100) is a controlled language with a limited vocabulary and restricted writing rules; it has limited scope for creativity. Simplified Technical English was developed to make technical documents easier to understand for people with very little English. Despite its name, STE is not an easy language to learn through self-study. Authors can spend their entire careers writing technical documents in STE and never fully grasp it. With its stringent rules, mastering STE is similar to learning a new language in some ways.

Goals of Simplified Technical English

The main goals of the created document were quite understandable:

  • Reduce ambiguity.
  • Improve clarity of the technical text.
  • Make user manuals more comprehensive for non-native speakers of English.
  • Create better conditions for both human and machine translation.

The STE guide is still acting as part of several standards used in the aerospace industry. It includes regulations of grammar, style, and wording in procedural and descriptive texts. For example, it includes a dictionary of about 850 approved general words. With its help, technical documentation became more readable, easier to maintain, and cheaper to localize.

Simplified Technical English Rules

Simplified Technical English is split into two parts: writing rules and a dictionary. Here are the simple steps to help implement STE.

  1. Delete non-relevant information. Technical documents may contain additional information not relevant for the end-user to complete the task. Before removing all non-relevant information, ask yourself this question: Does the user need this information to complete the task? If the answer is no, remove it.
  2. Use approved words. Writing clearly and concisely is essential. The same word can have different meanings for different people. Avoid ambiguous sentences that are open to interpretation. Use the STE dictionary to reword any dubious sentence.
  3. Less is more. Do not use more than three nouns in a row: ‘overhead panel’ is permitted, but ‘overhead panel battery section’ is not.
  4. Keep it short. The recommended maximum of a sentence is 20 words in a procedural sentence and 25 in a descriptive sentence. However, a short sentence is ineffective when it contains more than one instruction or topic, particularly in a procedure. Splitting your sentences into single points makes technical content easier to read. In procedural writing, write the verb in the imperative form. A paragraph must be at most six sentences long.
  5. Never use the passive voice in a text, but always use an active sentence: not 'The screws should be replaced' (by whom?!), but 'The mechanics replace the screws.'

Simplified Technical English Examples

In the following table, you can see some Simplified Technical English examples compared to standard English (the examples are taken from the Specification ASD-STE100, Issue 7):

simplified technical english examples table

Should You Use STE?

laptop

The STE guide was never meant to become a general writing standard. Nevertheless, it was successfully adopted by many industries (especially on the military side of things). The US government made an attempt to create a more general writing standard. That's how plain English appeared. They started working on this project in the 1970s aiming at a more cost-effective and easier-to-understand solution for government communication. The plain English concept certainly lacks the strict regulations of vocabulary that STE offers to technical writers, but it is a standard that can be used more generally.

If you are working in an aerospace/military technical writing team, you are most likely using STE. The same goes for the government sector and plain English. The rest of us should take notice of what is being offered by such regulations, as well.

Very often, a huge gap exists between complicated technical processes and what end-users know about the subject. A popular use case here would be the end-users knowing the subject on a higher level like knowing a UI in software documentation. And the job of a tech writer is to become a mediator between the readers and all the complexity that is going on behind the scenes. Style guides for technical writers offer a great platform for setting up regulatory mechanisms for technical documentation written in your company. Studying either the standards mentioned in this article or other widely applied regulatory documents can give you the helping hand you need to jump-start your own thing.

Conclusion

While we understand that it is impossible to unify and standardize everything due to the insane variety of documentation types and fields of knowledge tech writers are involved in, we are trying to provide you with tips and approaches to building your own unique technical language standard.

Good luck with your technical writing!
ClickHelp Team
Author, host and deliver documentation across platforms and devices

 

Give it a Try!

Sign up for a 14-day free trial!
Start Free Trial
Post Categories
Want to become a better professional?
Get monthly digest on technical writing, UX and web design, overviews of useful free resources and much more.
×

Mind if we email you once a month?

Professionals never stop learning. Join thousands of experts subscribed to our blog to get tips, ideas and stories from us once per month.
Learn more on ClickHelp
×
By using this site, you agree to our Privacy Policy and Terms of Use.

Learn more