This chapter attempts to tackle the question of how one goes about writing a technical document. It notes that there are several aspects that make technical writing different than any other kind of writing, but it does not detract from the fact that, like all other forms of writing, critical thinking must be used during the process. I will also review the processes of planning, drafting and critiquing a document that will precede the publishing of your technical writing. I will also cover the maybe self-explanatory point that proofreading must be the final step before publication. There are also many tools available nowadays that enable us to write technically-- these all have advantages and disadvantages.
It is true that the writing process, in general, is similar throughout all fields, but technical writing also has some uniques aspects. Research often precedes technical writing, and the type of audience to which you are writing will greatly influence how you will compile your document. When working in a corporate setting, you will also have to follow company guidelines and legal obligations when writing your document. Proper formatting is necessary, and distributing your document via hard copy or digital will make a large difference in the effectiveness of the information you are presenting. It should also be stated that deadlines will limit your writing more frequently when you are working in a corporate setting.
Critical thinking must also be applied across all the processes of the writing process. First, you must gather, evaluate, and interpret all of the information and ideas you have collected. Next, you should decide on how you will construct your document, including your purpose statement and how you will appeal to your chosen audience. Then, you must begin drafting your document. After you have some material, review and revision by a peer or manager is critical and after evaluations are collected you need to redraft your document. Finally, after your redraft and final proofread is complete, your document is finished and ready to be published!
One illustration that may be helpful to sum up the entire technical writing process that we have covered over the past six chapters is to consider the writer as a problem solver, and persuasion, ethics, information and collaboration are the problems that you seek to solve. This is a great example because it encompasses all of the processes and aspects of a typical writing problem that one may encounter is a corporate situation.
Proofreading should be the last step before your document is published, because there may be one or several easily correctable mistakes that may have been missed in the revision stage. Some of these errors include, but are not limited to, sentence errors like fragments or run-ons, punctuation errors like misplaced commas or missing apostrophes, and usage errors, which can mean a multitude of things ("it's" instead of "its"; "their" for "there"; etc.). Other errors include mechanical ones like misspelled words or inaccurate abbreviations, and formatting errors such as lack of page numbers (or mis-numbered) or incorrect formatting of sources. Typographical errors may also be found in a final document.
In addition to looking specifically for the above-mentioned common errors, you should also follow a few guidelines for proofreading. It should also be saved for the final draft-- proofreading any earlier may lead to unnecessary delays, like writer's block. I would suggest that you also take a break from your document before you do your final proofread. If you immediately proof a final document, you are more than likely to miss things. You should also do your proofing on a hard copy-- you seen things better, and are able to correct more, when it is in print! Also, slowly read over your final document-- this assures that you won't miss anything. You should also watch out for things you may have difficulty with while you are proofreading. For example, I am guilty of long run-on sentences and extra large paragraphs, so I watch for those things when proofing a lab report or other technical document. Also, you should proof your document more than once-- it's another way to avoid missing things. Finally, and this is probably the most important and the most often overlooked, don't avoid on the computer's spell check to find everything! It's not a person, so it doesn't know what you mean all of the time-- always, always, always remember that nothing replaces your own personal proofreading.
As technical writing has become more necessary in our technology-driven society, programs have been developed to better facilitate it. For example, Microsoft Word encompasses an outline feature which is great for early outlining of your document. There is also brainstorming and storyboarding software to better house your early ideas. The Diggo program also helps you archive important resources that you may need for your project. Powerpoint is an awesome tool for formatting presentations as well. Visio software also facilitates flowcharting and mapping. A useful tool for collaboration is Google Docs, which allows team members to simultaneously update a given document over the internet. Emails, text messages, and instant messages also help facilitate quick and easy group communication. Overall, even though there is so much technology at our hands to help us write technical documents, you must remember that it is ultimately your mind that creates the document and nothing is more powerful than your own personal critical thinking skills.
Group Discussion Question: Do you remember the writing process when you were in elementary school? I remember hand writing my paper, then handing it over to my friend for revision with a red pen, and when I got it back, I re-wrote it by hand and turned it in. I have only worked in the corporate world for about two weeks, but I have wrote lab reports with a group numerous times and I feel like the revision process was minimal to non-existent! What are some ways that we can bring it back in a technology-driven world?
Do you make time for revisions? If not, don't be surprised that the writing ends up being last minute and lacking. Ask your co-workers to consider introducing writing much earlier in the development process, so that it becomes a work tool and not just a way to communicate a result. Chances are the end product will be vastly improved!
ReplyDelete