One Saturday afternoon I went to Home Depot to buy a 6-foot ladder that had been advertised in the previous Sunday’s paper for $39.95. I went to the ladder department, thinking that the logical place to find a ladder. Numerous ladders were there but not the one I was looking for. Convinced I was the victim of a bait-and-switch, I turned around and started to leave for my small, local hardware store, where the price would be higher but where I would be likely to find the object I so desired.

However, wonder of wonders, that almost extinct organism, aka the store employee whose job it is to help customers about to leave without buying anything, caught me at this weak moment and asked if he might assist me. After I explained my plight, he said to my current persona as damsel in distress, “Let me look it up in the computer!” He nearly flung his cape, er, HD orange apron, around in excitement.

Into the conveniently located computer, my hero typed a few entries, then turned to me and delivered the verdict: “There are 11 of these ladders in the store!”

Starting to feel a little like Alice in Wonderland—and feeling somewhat embarrassed about stating the obvious, I said in a small voice, apologetically, “But, where are they? They are not here in the ladder department.”

Within minutes, four Home Depot guys were scouring the store for my $39.95 ladder. That’s when I realized that Home Depot needed some product indexing.

Indexing is building whatever is being indexed backwards. It really does not matter what that is. The same process works whether indexing a book, a Web site, series of journal articles, or a hardware store. The idea is to provide users with all the references to a particular subject that appear in that book, or item in the store, so they can find it relatively quickly and easily.

Indexing imposes restrictions that you may find odd, if not completely in opposition to your usual way of working as a technical communicator:

  1. Skim the material; don’t read it; or you will never finish the job.
  2. Combine similar terms, instead of increasing nuance with details.
  3. Use only one grammatical form (e.g., gerunds), even though the term in the text may appear as a noun, verb, participle, gerund, and whatever else you can imagine. (This requirement flies in the face of the technical communicator's overwhelming preference for precision.)

This may not be possible for you. That’s OK. After all, I’ve never done computer documentation. Furthermore, you may find indexing

  1. Boring
  2. Less than exciting
  3. Frustrating—because you really cannot read or edit, for that matter, the work simultaneously with indexing it!
  4. Mathematical—and math anxiety is not an uncommon phenomenon.

By mathematical I mean….

Indexing involves the ability to view the work being indexed more or less simultaneously as both a forest and a collection of trees, undergrowth, mammals, insects, and birds. The indexer deals with the big picture—in the form of chapter titles and subtitles or separate Web pages and how they relate to the overall subject of the work. At the same time, the indexer must predict what users might also need to discover about all the details covered. Furthermore, the indexer must also have the discipline to whack away at the draft deliverable because the propensity to “over-index” is endemic to anyone who deals with words, even when those words are organized in what might be perceived as a mathematical—or architectural—way.

Eventually, my ladder was found in the paint department. Yes, that is somewhat logical—but only as a double-posting, if I may insert some indexer jargon. Double- or sometimes triple-posting is simply a way for readers to find entries both as “stand-alone” and as they relate to larger subjects. In other words, if Home Depot had an index for items sold in the store, it might have included the following entries, among others:

SKUs, location numbers (only comprehended by hardware store cognoscenti, and not us less fortunate customers), or other retail hardware jargon could be used as the “locators”—the “xx” after the commas in the entries and subentries above. Locators are page numbers in a book and URLs for a Web site.

Making the judgment as to just how much detail is needed is a matter of experience and knowledge of one’s audience (yes, that ubiquitous audience factor again). Different subject matter—an indication of audience composition—requires different levels of detail. The index of an anatomy text for 3rd-year medical students will be vastly more involved than a high school biology book, for example.

Moreover, sometimes the authors demand greater detail in the index than the book’s subject, length, and audience would warrant, at least according to the indexer. Under these circumstances, you really don’t have much choice but to go along with whatever the author wants, provided the publisher understands that the resultant index may increase the length of the book by 12 pages or more. Sometimes authors want additional entries simply to ensure that their names and/or the titles of their other works appear as often as possible.

When techcomm types talk about Information Architecture, I immediately think about indexing. Maybe indexing is building the work backwards, or from the top down, and architecture is inherently a “building up” activity. But the process is not that much different.

Courses, books, and other materials can show you how to index. Developing an index without getting “lost” involves adhering to the work’s organization; dedicated indexing software helps, too (not Microsoft Word’s indexing function, however!).

Searching the index, alas, is a matter of audience knowledge and experience.

Thea Teich has been a member of the SWO chapter since 1988. A past SWO president, Thea was also president of STC in 2003-2004. She has worked in the field of technical communication for more than 30 years, the last 11 as the owner and principal of Teich Technical and Marketing Communications.