The service manuals of yore

When I gave up my workbench and oscilloscope in the R&D lab for a desk in Field Service Technical Publications, I learned to structure product service manuals in this way:

• Introduction
• Theory of operation
• Controls
• Removal/replacement/adjustment procedures
• Field-replaceable units
• Installation procedures
• Fault isolation tables
• Technical specifications

This was the One True Structure, handed down from on high. (I think it was probably carved on stone tablets, but since I didn't work at headquarters, I never saw them.) Nobody questioned The Structure. Nobody asked whether it made information easy to find.

In truth, it was worse than that. "User-friendly" was a derisive epithet, uttered with a sneer. Were our field service engineers such a bunch of babies that they couldn't handle a proper 350-page service manual?

My goodness, how the profession has evolved since then. How our philosophy has evolved!

Sometimes I wish I could go back and rewrite my first manual using what I know now, and lead my benighted colleagues into the light. Great material, bad sequencing, I would tell them. Shorten the introduction to one page maximum. If our field engineers missed training on this product, they still know a printer when they see one, so just hit the high points. They're our engineers; you don't have to sell it to them. Installation procedures next. Then controls. Testing and fault isolation. Removal/replacement/adjustment procedures; roll the information about field-replaceable units into that chapter. Performance verification and technical specs last.

The clouds would part and angels would sing when the field engineers found that they didn't need to skip all over the book to find the bits they needed. O, for a time machine to let me go back and light the way.

Bah.
Our whole profession marched boldly forward, through the dark times and into the light. We thought things through. We learned from each other and taught each other. Those ponderous 300-page manuals that seem to have neither rhyme nor reason are a thing of the past. We learned a new word: usability.

We technical communicators grade our work now on the percentage of help desk calls that are due to actual product malfunctions or defects rather than issues that our customers can resolve on their own. It's still important that the relevant information be documented, but now we know that information is only useful if you can FIND it.

We got there. No time machine required; just the magical alchemy wrought by time itself - time, and passion for communicating technical information clearly.