To create a technical document, a technical writer must understand the audience and purpose. The writer gathers information by studying existing material and interviewing SMEs. The technical writer also studies the audience to learn their needs and technical understanding level.
Like any profession, becoming a technical writer requires a mastery of a certain set of skills. This skill set used to involve primarily writing and illustration skills, as large manuals for print publication were the standard in the profession. The worlds of communications and technology have evolved dramatically in the latter part of the 20th century and the early part of this century. How has that evolution affected the skill set required for a technical writer?
Some business managers fail to recognize the impact on profitability of good technical documentation and other support literature, or the lack thereof.
You might hear them say—as I have—“It’s not really a priority at the moment” or “We may consider it later” or even “It cost too much, we’ll have to do without it”. And yet, with your eyes and ears open, you will learn that:
- Many industrial accidents happen because of inadequate procedural documentation or training.
- Many high-tech products fail in the marketplace because customers don’t receive the information they need to use them effectively.
- Many investments in costly new business systems fail to achieve results because structured training and user assistance materials are not part of the plan.
Technical writers can add a great deal of value to your products or services.
The Society for Technical Communication (STC), the professional organization for technical writers, is involved in a movement to re-classify technical writers as technical communicators. A similar effort is also underway in the United Kingdom. To some technical writers, this movement is a bit contrary to their self-image as professional writers, while others welcome the change and agree that technical writers are increasingly tasked with creating technical communications in a growing variety of mediums beyond the written word.
Wondering where technical communication is headed, in 2010 and beyond? Sarah O’Keefe, Ellis Pratt, and Tony Self offer their insights.
There are plenty of definitions regarding Rapid e-Learning. A lot of them are variations of strange theories. But, I have only one definition:
“Rapid e-Learning is the development of learning courseware within a short timeline, which is achieved using basic templates which form a static framework and contains the learning content.”
This implies that not much time is spent on creating complex and pretty animations and interactions. There is debate aplenty in e-learning circles and many people may consider e-learning not valid unless it has a high level of interactivity, pulsing text and images and other bells and whistles, such as nonsensical games. Anything less may be considered as boring click-and-read material. All this just adds extra time (lots of it) and extra expense.
It is easy to disguise poor instructional design with slick effects and animations. However, a lot of this stuff is neither necessary or effective and I believe all these repetitive flying, flashing texts and images can trigger extreme irritation.
According to the United States Department of Labor (DOL), the official description, written years ago, of the technical writer’s responsibilities is the following:
“Write technical materials, such as equipment manuals, appendices, or operating and maintenance instructions. May assist in layout work.”
Today, communication covers much, much more. STC members do much, much more. Their work is dynamic and interactive. The old definition isn’t nearly broad enough.
Read the original article at http://www.stc.org/story/tc_tw.asp
I bring this article to you courtesy of Gryphon Mountain Journals, as I think it adds enormous pertinence to what I do. You may view the original article here.
In our ongoing department reorganization, we technical writers are experiencing some angst as we carve out a desirable place for ourselves. However, as we’ve talked about it as a community of practice (no longer as an organized team with our own manager), I think we’re coming to an agreement that now is the time to make things happen—to strike, as Tom likes to say.
I bring this article to you courtesy of UXmatters, as I think it adds enormous pertinence to what I do. You may view the original article here.
Making the Deal: Supporting Product Demos with User Assistance
By Mike Hughes
Published: August 23, 2010