TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Re: Resolved: Technical communicators can create information
Subject:Re: Resolved: Technical communicators can create information From:Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Mon, 21 Jun 2010 05:54:21 -0700 (PDT)
Steve says:
"Obviously, the most valuable of the three is creating information,
though here my astronomy analogy breaks down: I don't mean faking
signals from space 8^) SMEs can create information. Can we? Chris's
definition makes it clear we can, and John recounts how he did. I think
organizing and clearly presenting data, even data from SMEs,
constitutes creating information."
When I first joined in on this thread, I provided an example that specifically holds your astronomy analogy together for creating information -- Kepler's three laws of motion. In the DIKUW hierarchy, Kepler created understanding. But the point is, with Kepler's laws we can describe any object in space with only limited data (to a degree, before relativity throws things into a tizzy). With that information/understanding we can do things like fling people to the moon and back. Kepler created those laws, hence his moniker is attached. In our humble way, we can do the same.
I like to think that the tech writer value proposition includes setting up users with enough understanding to use the product in their own environments, and think through unique problems without resorting to technical support. There are two important points regarding SMEs:
1) Rarely does a single SME have all the information. The information package that we call a product is too big for a single person to keep it all in his head. So many SMEs provide a jumble of information/data which cannot be passed directly to the user. Too much detail here, too little there... Description of the technology, but not the how or why... We all know the drill. Pure journalism on the part of a tech writer simply will not do. We have to add structure, FORMulate, and IN-FORM.
2) Rarely do SMEs provide useful language. How often have you inherited a manual that was cobbled together as cut/paste of SME descriptions? Nothing damages the perceived value of tech writing more than the existence of such a book. We add value when we understand the product enough to describe it in language that is attuned to the reader.
Here's another value proposition... We check the usability. I keep a simple rule of thumb -- If I verify that I understand a feature, and I can't describe it reasonably, I can say the design is faulty. You can bet that I'll push back against that design, and try to get changes into the product. I have heard engineers say they didn't have time to make the changes. I have heard engineers say that I didn't actually understand the feature. I have even heard engineers say they simply won't change it. But I have never heard an engineer complain or tell me to mind my own business. Maybe I'm just lucky. But there's no question that getting writers into the design phase, where they can think through how to describe the product as designed, adds value and can save gobs of time/money. This is more than producing pages. In fact, it should reduce the page count. But it adds value.
I've said it many times and I'll say it again. A product is a package of information. The product cycle is an exercise in information management. We're information professionals. Those dots connect.
Gain access to everything you need to create and publish documentation,
manuals, and other information through multiple channels. Choose
authoring (and import) as well as virtually any output you may need. http://www.doctohelp.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-