Journals by RSS
Journals by Email
I knew from the email subject line that I wasn’t going to like what was in the message.
The subject contained the name of an application, then two frightening words: “help sheets.”
I’ve found that outside the tech comm profession, people tend to throw around terms like “help” and “tips” without really thinking about what they mean. That’s why I felt a bit of dread as I opened this particular email.
The Rogue Documents
Looking for feedback, the product manager had forwarded two Word documents from an instructor who teaches this particular application as part of a week-long training for office staff. The instructor had documented a couple of end-to-end processes that weren’t strung together like that in the help.
Let’s just say that these documents weren’t done by a professional tech writer. I didn’t even get down to giving feedback on a content level; a subject-matter expert did some of that. Instead, I was concerned that by giving these documents to the class members, we were providing an inconsistent and less-than-professional experience.
I was also concerned because these documents’ pages were numbered 35 through 41. So what else was there that we didn’t know about? How much effort was being duplicated? Since it’s my full-time job to create such materials, I would have preferred if the instructors let us know about the need and asked me to fill it. Frankly, it felt a bit threatening, as if I thought my job was in danger. I considered this “rogue,” or unofficial, documentation.
The Idea
I ignored this email until the next day. Then, however, I decided to change my stance. I realized this was an opportunity, not a slap in the face.
I called the product manager and suggested that we visit the class with the purpose of seeing if we at headquarters were providing everything needed for these instructors at the training center. It had occurred to me that this was something we should have done a long time ago, back when the application was rolled out. Instead, I had focused on documentation and training materials while remaining unconscious of the actual in-person training that was going to happen.
So sleeping on it did some good. My view the day after was much different than my initial reaction.
The Opportunity and the Result
The product manager thought this visit was a great idea. He, the SME, and I spent an entire day observing the classes and even provided corrections and additional information. We also found that our training system had some bugs in it that prevented the instructors from covering some important material—and from instilling further confidence in the application in the class members. Instead of letting us know, they skipped or worked around the problems.
It was an interesting parallel: We weren’t getting much feedback from the instructors on our materials and what they needed from us; at the same time, the instructors don’t get much feedback from class members on the quality of the training once they’ve begun their assignments.
I found out that the other “help sheets” covered the basics in programs like Word, Excel, and Outlook rather than our custom application. That gave me a little less to worry about.
As the three of us visitors discussed our findings later, the product manager pointed out that the class members were essentially being overloaded with information. They would forget much of what was taught in class and have to relearn it once they began their assignments. But at least they would remember having been exposed to it before.
At this point, I won’t be developing any standardized materials for the classes. But we decided, along with the instructors’ supervisor, that semi-annual visits would be beneficial so that our efforts will be coordinated. For now, the “help sheets” will probably stay as they are. But I took their existence as a cue to improve the help material on that subject to be more comprehensive.
I learned that when I encounter rogue documentation, instead of feeling threatened or replaceable, I should take it as an opportunity to analyze what I’m doing and where the holes are. It’s an opportunity to do my job better.
Art credit: Drawn and colored by Daniel Minson.
Related posts (auto-generated):
5 Comments to 'Making an Opportunity out of Rogue Documentation'
August 5, 2010
Good insight, Ben. Rogue documentation almost always exists because somebody thought there was a problem with the official documentation: either they couldn’t find information, or the information somehow wasn’t suitable. Your approach — seeing this as an opportunity to analyze your work and consider improvements — is spot-on.
August 5, 2010
I’ve encountered rogue documentation any number of times in the past (and it’s often remarkably similar to first-draft documentation I’ve received from engineers and programmers).
After I get past the initial “ewwww” moment where I’m repulsed by the writing, “ransom-note” formatting, dreadful screen captures and completely uninformed use of tools like Microsoft Word, I look at what the author has actually tried to accomplish. Did they create a document that pointed out a glaring hole in the existing documentation? Sometimes that happens. In spite of our best efforts, we sometimes fail to fill an obvious need. Rogue documents can serve as a check to help us make sure we’re doing our jobs well.
If I can, I’ll just jump in and do a quick tweak on the document and make it available to the original author. I try to give it a similar look and feel to what I’m creating myself, correct some of the glaring writing flaws.
August 5, 2010
I had a rare opportunity once to manage both the training department and the doc department. I initiated the policy that the only documents trainers would develop would be agendas and exercises (as in problem based scenarios, not instructions). The idea was to get students used to the documentation by making them use it during training. If an instructor felt a need to make a supplementary reference or job aid, we incorporated it into the user doc. The end result was very good. Training exercises gave our writers real world insight into what the document had to support, and the trainer’s insight into useful job aids made the documentation richer.
August 7, 2010
Thanks for the comments, guys. This is one of those areas where I’m learning by trial and error, given that I didn’t have anyone to learn from when I was first hired, and I’ve stumbled as I went along. Something I didn’t mention in the post, but that I was addressing, is how sometimes tech writers for commercial entities try to outdo “some dude’s blog” and also make the docs findable so that they can stay employed. That kind of rogue documentation, coming from outside our organizations, can certainly make us feel a bit threatened, but they still provide that opportunity to check ourselves.
August 7, 2010
One issue that wasn’t discussed here is when those rogue documents become public documents. As we say here in Wisconsin, that’s when the cheese becomes more binding. As technical writers, we’re obligated to follow the corporate style guide (in some cases, we *are* the corporate style guide [grin]). Then some well-meaning engineer, programmer or trainer creates a document that gets released to the world and not only doesn’t it look anything like the well-designed and formatted “official” documents, in some cases it looks like a ransom note. And we want to say to the person who created it “How dare you put that document out there for the public to see!! It makes our company look like crap!” but we choke back the bile, thank them for their contribution and (assuming we’re permitted) fix it for ‘em. Ah, it’s a great life if you don’t weaken.