Supporting Decisions, or Helping the Fighter Pilot

While rtfm* concentrates on creating effective user manuals (i.e. ones that actually get read), my personal definition of technical writing is that it "helps people do something or make a decision." A useful way of thinking about that 'making a decision' part is to use John Boyd's OODA loop (John Boyd is a personal hero).

The loop's four components are (from Wikipedia, slightly amended):

• Observation: the collection of data
• Orientation: the analysis and synthesis of data into already existing information
• Decision: the determination of a course of action
  
• Action: the physical playing-out of decision

Effective technical writing has to support those first three steps. That's only possible by understanding rtfm*'s mantra of Audience, Scenario, Purpose:

• Observation: You don't want to present all the data but to concentrate on the useful/relevant data. That's only going to be possible if you know who the audience is, what scenario they will follow for making the decision, and what the audience's purpose (or goals) are. For instance, there's no point presenting information that isn't relevant to the decision making process; by and large, you don't want to present information already known to the audience (instead, you want to concentrate on information that's new to the audience); you want to present information that will help readers achieve their goals.
  
• Orientation: For the information that you're providing to be useful to the audience, the reader has to be able to integrate it into what they already know. This means, for instance, at the very least, using units of measurement that are comparable to the other data that the user will be working with. Technical writers, if they know the audience and scenario well enough, can even do some (or all) of the integration work for the reader by showing how the new information relates to what the audience already knows.
  
• Decision: In most scenarios there are a limited number of options that are available to the decision maker. Technical writers can outline the options, supply criteria for selecting among them, show what observations lead to which decisions, and show how different purposes can be achieved through different decisions.
  

OODA is a loop, so after the decision-maker takes action, the decision-maker goes back to the observation step. One part of the second loop is going to be an assessment of the result of the previous action. Technical writers can support that also by providing criteria for assessing success, spotting deviations from the expected results, and dealing with problems.

Boyd started out as a fighter pilot so, for him, a critical success factor is how quickly a person can move through the OODA loop. People who process the loop faster are making more decisions than their opponent, are reacting to the current situation rather than the past, and (generally speaking) have an advantage over others (the terminology is that you 'get inside' your oponent's loop). Supporting the OODA loop--even if your not in a warfighting environment--allows your reader to make decisions faster.

Helping make your readers make "better quality" decisions, however, depends on the content you provide.

Reading or read:

• Today's Best Military Writing: The Finest Articles on the Past, Present, and Future of the U.S. Military by Walter J. Boyne