#21406
Audience Analysis the Easy Way 
Audience analysis is more often a process of guesswork than of an in-depth inquiry into the mind and activities of the user. In fact, it is pretty easy to analyze your audience without having to do any research. Essentially, there are only two things that technical writers need ask themselves during the audience-analysis phase: what does the user know about the thing I am writing about? And what does the user want to know about the thing I am writing about?
Docsymmetry (2003). Articles>Rhetoric>Audience Analysis
#21405
A Career in Technical Writing: What Can You Expect?
What can you expect from a career in technical writing? The answer depends on a couple of factors. Specifically, will you be a lone technical writer or part of a technical writing team? Will you be a freelance technical writer or an employee?
Docsymmetry (2003). Careers>TC>Writing>Technical Writing
#21411
Editing Your Own Documentation
Technical writers sometimes fall into the trap of thinking that the user is stupid. I have often heard technical writers say things like 'well, if the user can't figure that out, maybe he’s in the wrong job!'
Docsymmetry (2003). Articles>Documentation>Editing>Technical Writing
#21404
Getting a Technical Writing Job, Even If You Have No Experience
Technical writing jobs can be hard to get if you have little or no experience. But there are things you can do to improve your chances of getting hired.
#21403
Hiring a technical writer can be tricky, even if you happen to be one. Where can you find a technical writer? What characteristics should you look for? How can you tell a good writer from a bad one?
#21981
A well-designed user guide contains a copyright page, which provides copyright information for your company's products as well as for any third-party products mentioned in your document.
Amott, Lyndsey. Docsymmetry (2004). Articles>Intellectual Property>Copyright>Technical Writing
#21410
Glossaries can be quite difficult to write, mainly because some definitions require so much research. While many definitions can be found online, others cannot. For these, you will have to read standards, Requests for Comments (RFCs), and books—a lot of work for a three- or four-line definition!
Docsymmetry (2003). Articles>Editing>Glossary
#21408
Mistakes Technical Writers Make
Inexperienced technical writers typically make a number of avoidable mistakes, including parroting the SME and hard-coding xrefs. Here is a description of some mistakes to avoid.
Docsymmetry (2003). Articles>Documentation>Technical Writing
#21407
I admit that I don't know everything about subject-matter experts or SMEs (rhymes with please). But I do know that there are some things that you should avoid asking SMEs, the main ones being 'Does the user know this already?' and 'Do I need to explain this to the user?' The problem with these questions is that the SME is likely to reply 'No!' to both of them when in fact the answer is most definitely 'Yes.' SMEs tend to believe that everyone knows as much about technology as they do. Never, never, never let the SMEs tell you how to write the documentation. A SME is the subject matter expert, not the documentation expert (that's you).
Docsymmetry (2003). Articles>Documentation>Collaboration>SMEs
#21412
In the United States, many technical writing courses and degree programs exist for hopeful writers. Technical writers in other countries are not necessarily so fortunate. I don't know why this should be so, but I am happy to say that this situation is improving; more and more universities and colleges are offering technical writing degrees and certificates. Since the number of schools offering technical writing programs changes frequently, providing a list of them here would soon cause this page to become out of date. To find out what technical writing courses are available in your area, contact your local universities and colleges. If there are no classes offered in your area, some universities and colleges provide online degree programs that you can complete from anywhere in the world. Also, many private companies provide technical writing courses. You can find these by typing "technical writing courses" at the search engines. Even if your local university or college does not offer any technical writing courses, you can take other courses that will be beneficial when you apply for a job.
#21409
The technical writing process consists of four phases: planning, writing, delivery and archiving. The phases of the technical writing process are not necessarily discrete. You might start the writing phase before you complete the planning stage, for example, or you might have to deliver the documentation before you feel it is finished. It is highly unlikely, however, that you will ever archive the documentation before you deliver it! Some products are released several times. In this situation, you might be in the delivery phase of the first iteration of the project while you are in the planning phase of the second iteration. Don't panic: overlap in the technical writing process is quite normal.
Docsymmetry (2003). Articles>Documentation>Workflow>Technical Writing
#21979
A Visual Guide to Document Design and Layout
Technical publications departments in their infancy seem to have great difficulty producing documentation that is well designed and consistent in appearance throughout all documents. As the department matures, it attempts to "consistify" the appearance of the documentation, but, unless there is an experienced template designer on board, this is often a drawn-out process involving focus groups and much squabbling. Once the design is complete, however, it tends to be nearly identical to the templates designed by every other technical publications department in the world. Aside from a handful of design features that distinguish the look and feel of one company's documentation from that of its competitors, everything else is pretty much the same. Whether the focus group spends six months or two years designing templates, they all discover that a well-designed user guide contains some specific and standard design elements.
Amott, Lyndsey. Docsymmetry (2003). Resources>Style Guides>Design>Documentation
