You Don’t Need A Map If You Know Where You’re Going

1. You Don’t Need A Map If You Know Where You’re Going By Allen Yale Harris

2. About the Author • Freelance Technical Writer • Taught inter-personal relations at USC • Frequent speaker at COMDEX

3. Article Information • Not found in journals • Probably author’s only article • Written out of anger?

4. Technical Writing Process • User manuals • What do you think a technical writer needs to keep in mind while writing a document?

5. Technical Writing Process • Audience (probably most important) • Knowledge of product • What can this product do? • Knowledge of tools to create document • Software • Good design techniques • Bad design can be infuriating to a user

6. Audience • Wide variety of audiences for a wide variety of products • They should match up • However, this article presents a problem with intended audiences

7. Misconception of Audience • “Software manuals are often written by people who already know everything about the program and never stop to consider what a beginner really needs to learn.” • “But the major problem is developers write manuals perfect for power users not novices.”

8. Problem • “Users don't read software manuals. They don't read manuals and it costs you money. It costs you money because of the many tech-support phone calls that wouldn't have occurred if your users had read your manuals. Management at one software company says 50% of tech support calls were answered in the manual. Tech support answering those questions costs that company thousands of dollars each year.”

9. Discussion • Do you read user manuals when you buy a product? Do you find them useful? • Do you still think certain products need user manuals even though they may never be used? What issues should be addressed? What are possible alternatives?

10. Group Activity #1 – Evaluation of “Bad” Documentation Group 1 http://www.techstandards.com/pdfs/2003WinningEntry.pdf Group 2 http://www.techstandards.com/pdfs/2003_Runnerup1.pdf

11. Group Activity #1 – Evaluation of “Bad” Documentation Group 3 http://www.techstandards.com/pdfs/2003_HonorableMention1.pdf Group 4 http://www.techstandards.com/pdfs/2003_HonorableMention2.pdf

12. The Author on Bad Documentation • “While rewriting a communications software manual, I tried to learn to use the program via the original user guide. I pestered the senior programmer for hours. He kept saying, "It's in the book." But the words in the book didn't make sense. Once translated, of course, they did. But they shouldn't require translation.”

13. Discussion • After reviewing these awful samples of bad documentation, describe how you think good documentation should look like

14. Group Activity #2 • Toys! • Using Word, create simple documentation with the toys given to you • Establish an audience and make sure it is consistent throughout

15. Conclusion • Technical writing is vital to those who need guidance in a particular product • It should be written clearly • It should reach the proper audience