September 6, 2011
At your company, which organization owns the red-headed stepchild named Tech Writing?
This question has always been an interesting topic of discussion in my little world. Do the design engineers and developers own it? Marketing? System engineering? Customer service? IT? Or is an independent jellyfish that floats through the company with marauding stingers of nuisance?
Most companies don't give it much thought, but they should. The reason? Perspective.
Technical writing only exists to solve a problem. You can't solve a problem if your perspective doesn't let you see it.
Let that sink in because there is a lot of good stuff in that little paragraph. Let's take the part about technical writing only existing to solve a problem first.
In a perfect world, products would be....well perfect. And perfect products are completely intuitive. Remember when Apple invented the Trash Can? Pretty perfect. Everyone who was a possible customer for their Macintosh knew what a trash can was so it didn't take much explaining to use it.
Now let's think about who they were competing with, the evil Microsoft/IBM alliance. In order to delete files on a PC, you had to understand a bit about MS DOS and that included a lot of commands, command prompts, file structures and a bunch of other stuff that resulted in a boxed set of documents delivered with each PC that rivaled the largest set of encyclopedias known to man. The tech writers were trying to solve a business problem because PC customers did not intuitively know how to delete files.
In a world without problems to solve, no documentation, and therefore no technical writers are needed. So there's your first solid gold tip for the day. Want to get rid of all that annoying documentation and expensive technical writing? Strive toward intuitive perfection!
Of course, nothing is perfect in this world so despite your best efforts, you are still going to need some documentation to support your business. And that brings us to the part about perspective.
Consider this. If the technical writers who supported the PC were part of the design engineering team (I don't know if they were, so just go with me on this), they were probably some pretty smart folks. Computer savvy. They understood everything about how that PC worked from the inside out. Now imagine how the documentation might read. You guessed it. It looked like that box of encyclopedias they shipped with every PC. I remember looking through that stuff for hours trying to find basic information to no avail.
Why was it so bad? Perspective. What probably happened is that the technical writers were directed by the designers who did not have an end-user perspective. The writers were instructed to write epic works to glorify every glorious detail of the designer's work. No matter how hard the designer's tried, they could not understand how to explain things for a novice computer user. The PC wasn't so hard to use. It was the documentation that was useless!
The PC world never really solved this problem until they copied Apple's point and click window interface. Suddenly the gargantuan box of encyclopedias disappeared from the PC shipping container.
How could this have been improved short of stealing Apple's GUI? IBM had a customer service organization. Actual Americans used to answer questions from actual customers all day long. By placing the technical writing activity under customer service, IBM could have grown the PC market much quicker because this documentation would have been the direct result of addressing end-user needs.
Is placing tech writing under customer service always the right answer?
No. Some companies may not have a customer service group. In the case of business-to-business sales, the product marketing group may be the one most in tune with customer needs. Sometimes it's sales. Often it is system engineering. If it's internal documentation or legal stuff, then maybe human resources should be the owner.
The answer varies. The point is think! Which organization has the best perspective for solving each individual problem? Picking the right owner may be the only decision you need to make to improve the business value your company's documentation.
Here's a final warning. Many companies make the mistake of putting technical writing under the development or design groups. Why? Because during product development, the only folks who know anything about a product (we call them Subject Matter Experts or SMEs) are the designer/developers. This is a dangerous practice and if you want to know why, think about the previously described IBM PC example.
I contend that producing a lot of useless information is worse that doing nothing at all. It costs a fortune. It creates a mountain of junk that now has to be maintained. It wastes the end user's time and frankly just pisses them off.
Art Fischman
art@business-writing.us
At your company, which organization owns the red-headed stepchild named Tech Writing?
This question has always been an interesting topic of discussion in my little world. Do the design engineers and developers own it? Marketing? System engineering? Customer service? IT? Or is an independent jellyfish that floats through the company with marauding stingers of nuisance?
Most companies don't give it much thought, but they should. The reason? Perspective.
Technical writing only exists to solve a problem. You can't solve a problem if your perspective doesn't let you see it.
Let that sink in because there is a lot of good stuff in that little paragraph. Let's take the part about technical writing only existing to solve a problem first.
In a perfect world, products would be....well perfect. And perfect products are completely intuitive. Remember when Apple invented the Trash Can? Pretty perfect. Everyone who was a possible customer for their Macintosh knew what a trash can was so it didn't take much explaining to use it.
Now let's think about who they were competing with, the evil Microsoft/IBM alliance. In order to delete files on a PC, you had to understand a bit about MS DOS and that included a lot of commands, command prompts, file structures and a bunch of other stuff that resulted in a boxed set of documents delivered with each PC that rivaled the largest set of encyclopedias known to man. The tech writers were trying to solve a business problem because PC customers did not intuitively know how to delete files.
In a world without problems to solve, no documentation, and therefore no technical writers are needed. So there's your first solid gold tip for the day. Want to get rid of all that annoying documentation and expensive technical writing? Strive toward intuitive perfection!
Of course, nothing is perfect in this world so despite your best efforts, you are still going to need some documentation to support your business. And that brings us to the part about perspective.
Consider this. If the technical writers who supported the PC were part of the design engineering team (I don't know if they were, so just go with me on this), they were probably some pretty smart folks. Computer savvy. They understood everything about how that PC worked from the inside out. Now imagine how the documentation might read. You guessed it. It looked like that box of encyclopedias they shipped with every PC. I remember looking through that stuff for hours trying to find basic information to no avail.
Why was it so bad? Perspective. What probably happened is that the technical writers were directed by the designers who did not have an end-user perspective. The writers were instructed to write epic works to glorify every glorious detail of the designer's work. No matter how hard the designer's tried, they could not understand how to explain things for a novice computer user. The PC wasn't so hard to use. It was the documentation that was useless!
The PC world never really solved this problem until they copied Apple's point and click window interface. Suddenly the gargantuan box of encyclopedias disappeared from the PC shipping container.
How could this have been improved short of stealing Apple's GUI? IBM had a customer service organization. Actual Americans used to answer questions from actual customers all day long. By placing the technical writing activity under customer service, IBM could have grown the PC market much quicker because this documentation would have been the direct result of addressing end-user needs.
Is placing tech writing under customer service always the right answer?
No. Some companies may not have a customer service group. In the case of business-to-business sales, the product marketing group may be the one most in tune with customer needs. Sometimes it's sales. Often it is system engineering. If it's internal documentation or legal stuff, then maybe human resources should be the owner.
The answer varies. The point is think! Which organization has the best perspective for solving each individual problem? Picking the right owner may be the only decision you need to make to improve the business value your company's documentation.
Here's a final warning. Many companies make the mistake of putting technical writing under the development or design groups. Why? Because during product development, the only folks who know anything about a product (we call them Subject Matter Experts or SMEs) are the designer/developers. This is a dangerous practice and if you want to know why, think about the previously described IBM PC example.
I contend that producing a lot of useless information is worse that doing nothing at all. It costs a fortune. It creates a mountain of junk that now has to be maintained. It wastes the end user's time and frankly just pisses them off.
Art Fischman
art@business-writing.us
No comments:
Post a Comment