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.
There's a shift happening in the way in which documentation is produced. We’ve all seen the beginning of it: the growing volume of what’s called (among other things) user generated or crowdsourced documentation. That trend is growing. And while a number of people in our profession are still resistant to the idea, it’s only a matter of time before users are our main partners in creating documentation.
Although the creation and translation of technical documents are essential parts of the product lifecycle they still play a subordinate role in most international organizations. Many companies are therefore leaving these tasks to an outsourcing provider. To ensure a smooth collaboration and guarantee high quality technical documents, the outsourcing process needs to be planned and supported thoroughly.
When the subjects of usability and user friendliness in relation to documentation are broached, writing isn’t often the first thing that comes to mind. But it should be.
Often conflicting pressures to produce communications that better fit customer demands as well as stay within tightening constraints on budgets and schedules are leading many technical communications organizations to a topic-based approach to authoring. In fact, 58% of participants in Aberdeen Group's October 2008 DITA and the Technical Communicator’s Transformation study report that they currently follow author content in a topic-based manner, with a vast majority of those remaining planning to implement one in the future. A topic-based approach promotes greater content reuse and is seeing a considerable impact on the authoring efficiency of technical communications projects today. The benefits of topic-based authoring can be compelling, with findings from the The Technical Communicator’s Transformation study indicating that when pursued the right way, topic-based authoring can have a broad range of benefits, enabling an organization to meet authoring and localization cost targets as well as documentation quality expectations, among others. However, as the adoption of this approach spreads, the advantages seen by today's leading organizations will flatten out. This Sector Insight provides a guide for current adoption of topic-based authoring and those still considering it; outlining the changes that are expected to take place in as topic-based authoring goes mainstream.
Recently a reader wrote me asking for advice on changing careers into technical writing. I asked for some colleagues to respond. Bill Albing, an information architect in North Carolina, and Alyssa Fox, a technical communications manager in Texas, responded to the question. With permission from Bill, Alyssa, and “Cedric” (the name I’ve given the reader), I posted the conversation here.
Chaucer's "Treatise on the Astrolabe," recognized as "the oldest work written in English on an elaborate scientific instrument," belongs with the new fourteenth-century movement of translating into or writing in the English language material that had customarily only appeared in Latin.
After being hired for my first technical writing job, I learned some background information about the hiring process that I believe any student or recent graduate would want to know.
I like the concept of not treating the readers of documentation like idiots. This little card gave me the information that I needed and couldn’t know ahead of time (how much water to use, the filter looks too big but is the right size, only push the button once) without wasting my time by giving me information that I either already knew or could easily guess (I can get water from the sink, I need to use a cup). Can we use this concept in software documentation? What parts can safely be left out so that we are only highlighting the pieces that are really needed?
Writing is a complex, cyclical task. The writing task requires more than formulating text to express ideas, it involves data gathering, managing constraints, formulating intentions, planning, and revising goals. Much of the complexity is due to the management of simultaneous activities and constraints. Management of these processes can lead to 'cognitive overload', which in turn can negatively affect the quality of the text produced. With technical writing, these same issues of task complexity are applicable.
I received the following email from Anna, a literature PhD candidate who is considering changing career paths from teaching into technical writing.
Collaborative walkthroughs are a technique that my team used while rewriting our Help and adopting DITA. We believe that we were able to improve the user experience by improving the collaborative experience.
College Writing Assessment is a website containing research and information on the evolving field of teaching of technical communication at the college level. It will include the results of our yearly assessments at New Jersey Institute of Technology, changing technical communication criteria, and our collaborations with other institutions.
Working successfully as a technical communicator involves a great deal more than a thorough knowledge of professional skills and capability in the craft. Working at this kind of job means dealing with all sorts of people, handling all sorts of assignments and dealing with all sorts of corporate agendas and requirements that have seemingly little to do with getting the project out the door. But it’s all in a day’s work, and if you want to keep the job, you’ve got to accept and actually operate within all of those guidelines, strictures, rules (written and unwritten) and mores that make up the corporate structure.
Companies place little emphasis on the quality of an engineer's writing. An engineer's writing is usually only for evidence a particular transaction took place, or for proof they did the appropriate research. There is hardly ever any emphasis on the readability or usefulness of the writing. In this article, the author states several reasons for this problem and that development teams must come to understand in order to find a solution.
Provides an introduction to our field’s connections with technology transfer and diffusion. Technology transfer, the complex social process that moves technology from bench to market, drives global economic growth; technology diffusion, the market-driven process by which innovations are adopted and implemented, follows similar patterns. Indeed, technology transfer and diffusion may be considered synonymous with the phenomenon of growth in a global economy.
STIC-leden kunnen zich uitstekend vinden in het competentieprofiel voor de Technisch Communicatie-specialist. Dat blijkt uit de resultaten van de enquête die de werkgroep Opleiding en Trainingen in het najaar 2007 aan de STIC-leden voorlegde.
The pages that follow describe the development of a grant proposal I wrote to obtain funding from an external private funding source. In the grant I proposed to research the programmatic options, student interest, and depart- mental/administrative support available for implementing a master’s degree in professional and technical writing (PTW) at my university.
One of the most important and difficult parts of technical documentation concerns writing in a concise manner. Technical writing is different than writing fiction or magazine articles, where a mood may be set or--in some cases--where space must be filled. (People seldom buy thin books.)
Mention team technical reviews to a group of tech writers and chances are good that you will either get a loud, collective groan, or the group will vie to tell the best review horror story. On the one hand, technical reviews are a vital part of our jobs because they help us to produce high quality product documents. On the other hand, technical reviews gone wrong are the bane of our existence. The good news is that we have the power to conduct consistently effective technical reviews. This article summarizes why we do reviews and what often goes wrong in reviews, and then summarizes steps to take before, during, and after technical reviews that can help you conduct effective team technical reviews. Although your process and team may differ from what’s described here, you can apply the information in part or in whole to improve your current review process.