Technical Writing, a form of technical communication, is a style of formal writing and business communication, used in fields as diverse as computer hardware and software, chemistry, the aerospace industry, robotics, finance, consumer electronics, and biotechnology. Good technical writing clarifies technical jargon; that is, it presents useful information that is clear and easy to understand for the intended audience.
In addition to common myths about technical writing as a sellout and fallback career, I can think of at least ten other commonly held myths surrounding the field of technical communication.
If you're a freelancer/contract tech writer, you need to promote yourself. Think of yourself as a store with exactly one product, namely your time. You can only sell that product to one customer at a time. What you need to do is make sure each sale is a good one, and that you sell as much of your time as possible, because no one pays you for down time if you're independent.
Are you a writer with an interest in technology? Do you want more freedom and greater control of your income? If so, perhaps freelance technical writing is for you. By using your skills to build your own client base, you can reap the following advantages.
If getting into the technical writing business is a challenge, and it assuredly is, defining our employment status often poses a few questions too. Naturally, there’s the common full-time employee status we all know and understand fairly well, but when we find ourselves dealing with a technical services or technical consulting firm there can be some murky waters, and more than a few aberrations of the “traditional” understanding of the term. So, we need to define some “terms” of employment since the majority of technical writers will ultimately encounter variations.
The rise of Web 2.0 technology provides a platform for user-generated content. Publishing is no longer restricted to a few technical writers—any user can now contribute information. But the information coming from users tends to be highly specific, whereas technical documentation is comprehensive but less specific. The two types of information can coexist and improve the overall user experience. User-generated content also offers an opportunity for technical writers to participate as “curators”—by evaluating and organizing the information provided by end users.
This paper discusses the author’s experience of teaching an English as a Second Language (ESL) technical writing class. The class consisted of students from several European and Asian countries who work for the same company as the author. The class began as an email “correspondence” class, but the author developed a web page which served as a “home” for the class to meet. As with most good classes, the teacher ended up learning as much or more than the students. This paper shares some of what the author learned from teaching.
Technical writers conceive, plan, and write documentation needed by their company or organization, including user guides, reference manuals, white papers, reports, and proposals. This paper describes one career growth opportunity: that of authoring a book that is published by a commercial publisher and sold in bookstores. The rewards of writing a book for publication include satisfaction in the jinished book, reaching a wider audience, and working with a professional publisher The goal of this paper is to encourage technical writers to consider this career path and to give specijic, practical advice on how to achieve it.
Products and tools must evolve to ensure that user experience does not suffer as technical writers evolve their delivery to suit this modern age. If a user has a question, there should be only one place to search, and those results should contain relevant hits from all possible content sources.
For some time now, machines have been constructed and built using modules. i.e. encapsulated and reusable standard components. In manuals, the modular approach has only slowly been gaining acceptance. With XML and a wide variety of editing tools, the technical prerequisites for the change are by now only a matter of the individual requirements â€“ a right solution can be found for virtually every purpose. But for technical communicators the question arises what needs to be considered when texting under these changed conditions. This language tip is intended to be a basic aspect: how can one determine whether a text component is suited as a module?
Most of us view government regulations negatively. Yet they provide a multitude of opportunities for technical writers. What are these opportunities? Where are they? How can you take advantage of them? A chance opportunity knocked on the author's door. Her experience can guide you to find and knock on opportunity's door.
Functional specifications (functional specs), in the end, are the blueprint for how you want a particular web project or application to look and work. It details what the finished product will do, how a user will interact with it, and what it will look like. By creating a blueprint of the product first, time and productivity are saved during the development stage because the programmers can program instead of also working out the logic of the user-experience. It will also enable you to manage the expectations of your clients or management, as they will know exactly what to expect.
One of the greatest problems manufacturers face is teaching consumers how to use their products. As I mentioned in a previous post, 95 percent of devices returned to stores actually work. That's a serious pain point and expense for manufacturers. Smart phones, tablets, and other computer-like devices are naturally moving in the direction of simple, digital instructions for setup.
With online help rapidly becoming the central piece in the documentation set, software companies might consider two different directions in their documentation planning. The first is to think of the user’s guide as a high-quality supplement to help. The second is to think of the user's guide as a transitional piece that will adequately support users while they make the transition to a largely online documentation set. Each of these directions carries different implications for the design of the user’s guide.
Gender-neutral writing uses language that does not stereotype either sex nor appear to be referring to only one sex when that is not the writer's intention. In this article, you'll see why gender-neutral writing is important for technical writers to use, what gender-neutral writing is not, and how you can use gender-neutral writing in the documents you develop.
In recurring discussions on the TECHWR-L list, many technical writers argue that they write in 'correct English' and are not going to change their style just to suit the political-correctness police. 'I won't use 'they' as a singular pronoun because it's not grammatically correct' and 'Using contrived phrases such as 's/he' is just too awkward' are arguments I've heard frequently in the debate. But using 'incorrect English' or contrived phrases is neither the goal nor the outcome of gender-neutral writing.
Gender-neutral writing uses language that does not stereotype either sex nor appear to be referring to only one sex when that is not the writer’s intention. In this article, you’ll see why gender-neutral writing is important for technical writers to use, what gender-neutral writing is not, and how you can use gender-neutral writing in the documents you develop.
For George Saunders, recipient of a MacArthur Grant and former technical writer, years working on reports and proposals proved to be excellent training for creative writing.
Most technical writers want their documentation to be perfect. That's a laudable goal. But you'll never achieve it. So, why not make your work as good as you can, and not stress about it not being perfect