What is Simplified Technical English?
by Sarah Eager
Let’s face it, Simplified Technical English (STE) can be boring. As a controlled language with a limited vocabulary and restricted writing rules, the ASD-STE100 document has a steep learning curve and limited scope for creativity. Although possible in theory, STE is not an easy language to learn through self-study. Authors can spend their entire career writing technical documents in STE and never fully grasp it. STE can be a headache at best, impossible at worst.
I’m one of the rare technical authors who enjoy it.
I started my career in the aviation industry where STE is ubiquitous. Largely self-taught, I’ve run courses on the principles of STE. At this point, STE is so deeply ingrained that I can’t read a book or watch a film with subtitles without translating into STE in my head.
Simplified Technical English was born out of necessity. By 1979, the aviation industry had grown to a point where there were countless civil aircraft manufacturers. Each created technical manuals for their aircraft in their own native language then translated them to English. These were then sold to different airlines around the world, who became responsible for the ongoing maintenance of these aircraft. To add to the confusion:
Naturally, this became a concern for the airlines tasked with maintaining aircraft, who began to push for greater writing standards across manufacturers.
To answer this demand, a collaborative project between the European Association of Aerospace Industries, Dutch aircraft manufacturer Fokker and the Aerospace Industries Association of America began. Four years later the Simplified English Guide was created. This guide would later become ASD Simplified Technical English, Specification ASD-STE100.
English is a rich language. Ask any fan of Shakespeare or Carry On films, and they can tell you that many words have ambiguous meanings and that English grammar can be very complex. Although English is the language most used for writing aircraft documentation, it is often not the native language of the users of the documentation.
For technical writers, the ability to convey complex information clearly and concisely is essential. Likewise, good writing skills using Plain English are a core business skill in any role.
STE is Plain English on steroids. This comes with several advantages that make it perfect for use in the aviation industry:
Reduced ambiguity – STE can make text easier to read and understand, both for native and non-native speakers. Removing ambiguities reduces the risk that the end-user will misunderstand the intended meaning.
Better translation and reduced costs – With a limited vocabulary and simple sentences, STE makes translation faster and easier, whether using human or machine translation approaches.
Improved reusability – As text is written using a standard approach, it is easier to reuse across documentation.
Despite its aim to improve readability, STE isn’t always suitable for general writing:
Standardised writing removes creativity – The more freedom a writer has, the more writing options they have. While this causes inconsistency amongst writers, it also makes using documentation more interesting, and even in some cases, fun (See our article on unusual user guides for some good examples).
Repetitive – STE intends to be repetitive. Although it improves reading comprehension and saves time on authoring, it can also make documentation dull and frustrating to use. This can hinder your efforts to make better use of your documentation, such as using it to complement your sales and marketing messages.
US English – STE is a form of English. Generally, American English is used; for authors used to writing in UK English, it can be hard to adopt. However, different spellings can be used if other style guides or official directives are in place.
Despite these drawbacks, the basic principles of STE can easily be adopted into, and improve, authoring style guides.
ASD Simplified Technical English, Specification ASD-STE100 is split into two parts: Writing rules and a dictionary. Below are three simple steps to help implement STE.
1. Delete non-relevant information
A lot of technical content contains additional information that’s not relevant for the end-user to complete the task. To remove all non-relevant information, ask yourself this question: Does the user need this word/information to complete the task? If the answer is no, remove it.
|The low-temperature engine lubricating oil that is used in the engine contains additives and chemicals which, if allowed to come into contact with the skin for a long time can be extremely toxic, due to absorption through the skin.|
The above example is long-winded and difficult to read. I got tired of reading it halfway through and I wrote it. Think of how difficult it would be to read an entire manual written like this.
Using STE we can strip out the unnecessary information and condense it into easier to read text, such as:
|Improved example Version 1|
|The oil used in the engine is extremely toxic, do not allow it to come into contact with the skin.|
This is better, but still not quite right. This brings us to Step 2.
2. Use approved words
The words you use in your technical documentation are important. Writing clearly, consistently and concisely is essential. What one word means to you can have a very different meaning to another reader. Take the word “should” for example. “After the test, you should turn off the engines” can have multiple interpretations:
Technically, no one is wrong. The above sentence is ambiguous and open to interpretation. However, when we use the STE dictionary to reword the sentence, Person B is correct as the approved alternative of “should” is a “must”.
By using the STE dictionary we can reword the earlier example to remove any vagueness. So our original sentence becomes;
|Improved example Version 2|
|The oil used in the engine is very poisonous, you must not let it touch your skin.|
Better, but there is still room for improvement.
3. Simple sentence structure
Keep your sentences short. The recommended maximum 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.
By splitting your sentences into single points, technical content becomes easier to read. In procedural writing, write the verb in the imperative form.
|Final improved example|
|Engine oil is poisonous. You must not let it touch your skin.|
STE is extremely useful for writing unambiguous technical content, particularly for user instructions where safety is critical. It is integral to the aviation industry where documentation must be in English and end-users may have a limited understanding of the language. It also has its advantages when using English as a base to translate into other languages, and, when done well, can cut down on the time to market for your documentation.
However, implementing STE is not an easy task. With its stringent rules, in some ways mastering STE is similar to learning a new language.
The implementation of STE can be incredibly expensive and time-consuming. For native English writers, it can take a long time for writing in STE to feel natural and the overheads tied to achieving compliance can be massive. It also may not be the best to use if your documentation needs to be engaging, or interesting.
So, while fully implementing STE might not be necessary or cost-effective for most organisations, taking some of the principles of STE can definitely help create documentation that is easier to understand, translate and write.
Although I’m still working on convincing my colleagues to include STE as part of our style guide, they do use some of its principles rather well. If you would like to find out more about how to create clear, user-friendly documentation, why not contact us here.
However, if you are looking to implement STE as part of your documentation, we can recommend Mike Unwalla at TechScribe, who you can contact here.
Sarah is a Technical Author and is based in our Edinburgh office. She enjoys working with technical customers and thinking of creative solutions to documentation challenges. Away from authoring, Sarah can be found writing baking recipes and cooking (Cheesecake and Miso Ramen are her speciality).