Troubleshooting is a subject that does not get much play in our circles. We talk a lot about usability studies, SMEs, and metrics. These are worthwhile topics, but I have a confession.  I spend very little time performing studies, chasing down developers, or proving my worth to my clients.

It’s true. I spend a good deal of time working through technical, connection, and application breakdowns, misfires and general screw-ups. My tech writer friends also spend a good deal of their time troubleshooting. In an ideal world we would spend our days writing. We would spin our prose into helpful instructions that are cherished by harried users. However, the most concise and informative instructions are useless if the user cannot access them. It don’t mean a thing if it ain’t got that swing.

Technical glitches can stand between our work and the end-user. So what to do when something goes wrong? Here a few informal troubleshooting steps:

1. Pay little heed to application error messages. They usually tell me nothing other than something has gone wrong. When I am on deadline and my compiled Help is only 10 kilobytes, I already know there is a problem. Okay, glance at the error message but do not dwell on it. From my experience, 90 percent of error messages are meaningless.

2.  Look to the past. Have you had this problem before? Save yourself a lot of headaches by documenting every problem you encounter and the resolution.  For example, the other day I created a compiled Help file, a .chm, and some of the TOC entries links did not work. When I clicked them, the .chm froze.

I looked into my Style Notes, an alphabetical .doc file I have been keeping for years and under “CHM Errors” I found the answer to my problem.  Keep track of pesky issues and rule over them.

3. Ask another writer. Sounds simple enough but another set of eyes can see the problem from another vantage point.

4. Use your own experience and intuition. There is no substitute for experience. When I was a rookie, I was sidelined by error messages, but now have enough experience and to make a fairly accurate diagnosis.

The reality is that our work involves more than the traditional tech writer tasks. It’s okay. Expect to troubleshoot. You will save yourself a lot of time and aspirin if you rely on your own experience and the experience of others.