The Technical Writing Process
Whether you're writing software manuals, online help, brochures, or scripting a video, the core goals of technical writing remain the same, the technical writer must learn to understand the technology, develop a body of information that can help the end user to understand and use the technology, then package and deliver the information to the user. Let's consider each of these steps individually.
Learn the Technology
Before you can explain the function and use of a computer program or piece of equipment, obviously you should be able to understand and use it yourself. Having background knowledge of the field you're working in will be a big help here. If you work for a software company as a technical writer, you don't necessarily need to be able to program a computer, but understanding something about the programming process can be immensely helpful both in relating to the programmers you will work with and in understanding the product your company produces.
As a technical writer for a hardware or equipment manufacturer you may be expected to perform basic maintenance on a product, or perhaps be capable of some assembly and disassembly. The more knowledge you have about your product, the better.
Talking with S.M.E.
Technical writers beginning a documentation product will often get much of their information from subject matter experts, or S.M.E. (often pronounced "SMEEZ").[Note: Since S.M.E. as defined here, is plural (experts), no 's' is added to the abbreviation in these lessons. Just read S.M.E. as a plural.]
The S.M.E. are generally members of the design and development teams on the project. They are the technical experts with a thorough understanding of how the product is designed and what it is capable of doing. They will know what improvements the company is trying to make over earlier models of the product, and how these improvements are being implemented.
One of the technical writer's main roles is to interview S.M.E. and translate their technical knowledge of a product into more generally digestible knowledge that will benefit the end user. If you are a member of the design team yourself and are tasked with doing the technical writing as well, this step will obviously not be as important.
Since, as the technical writer, you are in charge of writing the manual, you will find that there is no manual to help you as you learn how a given product works! The S.M.E. will come in handy here as well, giving you information on how to use the product so that you can get up and running with the task.
Learning for Yourself
Ideally, you will have time to play around with the product yourself, and learn by trial and error how it works. Doing this has advantages over working strictly with S.M.E. because by acting as an end user you will get an idea of what aspects of the product's use are simple and easy to understand and which are more confusing. When you write your user help, you will know which aspects of the product's operation will require more explanation for the end user. We will cover some techniques for learning new technology quickly in a later lesson, but remember that if you do have trouble learning something, it may not be your fault, but the product's.
While you learn, practice meta-learning. Be aware of your learning process. What aspects of the product interest you the most? The least? How similar or different from related products is this one? Document your learning as well. Take notes on what parts of the process you find the easiest, and which are the most challenging or confusing. If something seems excessively confusing to you, it might be the same for the end user. Bring any major concerns about usability to the development team leader. Essentially, technical writers are beta testers, or trial end users, for a new product, and quality design teams will take their concerns seriously.
]]>