Simplified Technical English: Who needs it?

Last night I attended the STC Austin program "Four Candles - Just What is Simplified Technical English?", presented by Alan Porter of Quadralay and the 4J's Group. (Do watch the Four Candles video if you don't know this famous skit!)

Simplified Technical English is a writing standard created for aerospace/defense maintenance documentation, born of a deadly need for clarity (such as the worker who obediently "cut the power" with loppers and died). It's a controlled language because it restricts grammar, style, and vocabulary. Its goal is to stamp out ambiguity (one word = one meaning) and present technical complexity in the easiest language possible, to support users of diverse ages, abilities, and familiarity with English. If this sounds like the Plain Language movement to you, you're right: there's significant overlap. Boiling it down, Simplified Technical English has two parts:

  1. Writing rules for simplified grammar and style (which improves readability scores)
  2. Control list (approved words with restricted meanings), plus guidelines for adding to the list and possibly a thesaurus (common terms with suggested alternatives)

The writing rules largely follow Plain Language guidelines and good technical writing practice, much of which can be enforced using Microsoft Word's Grammar Checker (all settings enabled):

  • Sentence length (20 or 25 words)
  • Paragraph length (6 sentences)
  • Noun cluster length (3 words or less)
  • Missing articles (based on count and mass distinctions)
  • Verbal auxiliaries (passive, progressive, perfect, modals)
  • Unnecessary -ing participles
  • Multiple commands in a single sentence
  • Warning, Caution, and Note errors (should begin with imperative statement)
  • Correct vocabulary and part-of-speech usage

Where STE becomes complicated and expen$ive is the control list: generally, paying for a QA tool (such as HyperSTE) to scan documents and ensure compliance with organizational rules and lists (which it can only do after you build an organization-specific dictionary and fully train the staff). Whenever possible, leverage an existing dictionary (Boeing, Kodak, Caterpillar), but relevant lists outside of manufacturing and medicine could be scarce.

The business case for implementing STE is the usual suspects:

  • Scary translation costs
  • Scary liability costs
  • Scary customer support costs

With none of these in play, is it worth it? No and yes: No to the formalized control list, but yes to the writing rules that yield readability improvements and consistency - which benefit every user, move content toward internationalization, and make any future translation projects less risky.