R.T.F.M.

If you work in I.T. you will no doubt have heard the abbreviation R.T.F.M. at some point. It stands for “Read The Frickin’ Manual”. As a Technical Communicator by trade it is always disappointing to hear it uttered. Hours and hours of research, learning and knowledge accumulation are pored into most software manuals, and all too frequently they are ignored.

“No-one reads the manual”?

So why do we bother? Like most professionals we take great pride in our work. We try and ensure that the information we present is technically accurate, written properly (frequently writing to ensure an easy translation is possible) and most importantly, of use to you the end user. So why don’t people use product documentation?

The advent of online help has moved the information you need into the product, so it’s only ever a button click away. Yet still it doesn’t get used. So what next? Microsoft tried to move things forward with the aforementioned Clippit. What was the customer reaction to Clippit? Well, new users loved it, but experienced users hated it. We now have applications that are led by the online help, stepping you through a task with additional information where needed.
So why doesn’t product documentation get used? Well, ask yourself this: if you experience a problem while using an application, what do you do? You ask someone else, or you search the web maybe, hoping to find a user forum, or possibly something on the company website that may help? Or do you just continue on within the application, hoping to solve your problem via trial and error? For the record I’ll plead guilty to all of the above.

Ultimately product documentation, of any form, presented in any manner, is never going to be well received. After all no-one likes to admit that they don’t know something and turning to the product documentation is an admission of failure. Factor in most people’s experience with poorly written product documentation from a few years back at the start of the PC boom and you have a recipe for, well, empathy I guess.

Most software companies have at least one technical author. That technical communicator spends many many hours thinking about you. Analyzing what you might need, creating user profiles, and trying to figure out how best they can help you. How best to structure the information they are producing and whether it is the correct kind, and in the right order and a multitude of other factors that are discussed at length every time two technical communicators get together.

So I have a plea: Next time you find yourself stuck, or if you experience a problem with your software, check the documentation first, and if you don’t find what you want, let the company know. Somewhere in that company is a technical communicator who is crying out to receive some valid feedback, something concrete they can use to improve their product documentation.

Those technical communicators are constantly striving to improve what they and their company offer, both in the documentation and as user advocates within the development cycle. Go on, throw them a bone.

Suggested Reading : What is a Technical Communicator? – http://stc.org/answers.asp