At my last job, I did a lot of marketing writing in addition to technical writing. This situation arose mainly because my last company had ~25 employees at the time, so we were all required to wear many different hats. Ask me sometime about my adventures in painting the bathroom.
I'd had classes in "professional writing" but no formal training in writing press releases or ad copy, although I did take a class in PR. Yet I found myself drafting these kinds of documents and reviewing them with my boss. What I found especially amusing was inventing quotes that the company president was supposed to have said. I guess up until then I'd assumed that quotes in press releases were, well, real.
It's interesting to me because advertising is seemingly in my blood: my uncle has a long history of corporate marketing positions and is now a freelance marketing consultant. My grandfather was an advertising guru as well, and I have a cousin who's a freelance ad designer (formerly employed at GSD&M).
Marketing might run in my blood but not in my brain. After several PR drafts and other non-tech-writing endeavors, I realized that although I enjoyed the theoretical implications of persuading people to pay attention to my company (with their brains, wallets, or both), I didn't enjoy the actual practice of persuasion. Technical writing suits me much better. I would rather dig deep into how a widget works and explain its operation to people than persuade people that purchasing this widget will solve their problems and make life complete.
As a tech writer, I interact with marketing folks on a regular basis, although perhaps less regularly than some other tech writers working on newer or more established projects. The marketing folk and I come from very different backgrounds but the core is the same: solid and effective communication. It's just that "effective" means something different for each of us. For me, "effective" means "the customer is successful in using the product to meet their needs or solve a problem." For them, "effective" means "the potential customer is made aware of our product and/or turned into an actual customer." Maybe Colin can provide some more insight here.
As much as I am not interested in marketing communication, the disciplines converge when I speak to college students in PR classes (for recruiting purposes). Although these students write all day long, they may not have heard about technical writing as a career option. So I have to do a little marketing communication (presentations, hand-outs, one-on-one chats, etc.) in order to make them aware of the opportunity. Perhaps if I were a better marketer and/or more effective at selling a career in technical writing at NI, we would have gotten a resume or two. As it is, I think we were pitching the wrong product to the wrong audience.
Additionally, sometimes I find myself editing bits and pieces of outbound marketing communication from our marketing people here at NI; typically it's been a little newsletter blurb about one of our product releases. The markeing people are not required to use us as editors as they have a different style that we do, but sometimes it might help a new or transitioning marketing person to get the tech writer's perspective. In these situations, I really have to hold myself back from going overboard with the red pen (virtual or real) and remind myself of the differences between marcomm and techcomm.
Whether you're communicating what a product's features are, or communicating how to use those features, both jobs come down to the same base: effective communication that achieves the goals you want.
May 23, 2006
May 1, 2006
Changing Expectations
I've been working at NI for a little over a year now, and I'm beginning to realize that working for this documentation team has raised my expectations any time I hit a Help button in any program. Raised my expectations to my benefit and aggravation!
The truth is, not every company that writes software has the ability to, or the willingness to, create a comprehensive Help like I think we do at NI. Tooting my own horn? Maybe a little. But even though we haven't produced a "perfect Help" for LabVIEW yet, we have a lot of folks here working hard every day to improve the supporting documentation in usability, scope, and detail. We're definitely some of the best Help I've seen.
On the other hand, just as I've learned to click the Help button in other programs expecting answers to my questions, I think a lot of other people have learned NOT to click the Help button in LabVIEW. Their expectations are that they won't find answers in the LabVIEW Help because they've been disappointed so many times before with other help systems.
In fact, today we had a tech support person bring us a printed copy of a web page with a topic that he said should go in the LabVIEW Help because it was so useful to the customer. Turns out, he'd printed a topic from the LabVIEW Help we just recently posted to the Web!
Funny. Frustrating. The incident might say more about people's comfort level with the Web as the ultimate documentation resource than about their confidence in the LabVIEW Help. Then again, it might also show that we need to continue marketing our own Help - even within the company.
I'd be curious to read more examples of great online help. Suggestions, anyone? I've got a list as long as my arm with bad examples...
The truth is, not every company that writes software has the ability to, or the willingness to, create a comprehensive Help like I think we do at NI. Tooting my own horn? Maybe a little. But even though we haven't produced a "perfect Help" for LabVIEW yet, we have a lot of folks here working hard every day to improve the supporting documentation in usability, scope, and detail. We're definitely some of the best Help I've seen.
On the other hand, just as I've learned to click the Help button in other programs expecting answers to my questions, I think a lot of other people have learned NOT to click the Help button in LabVIEW. Their expectations are that they won't find answers in the LabVIEW Help because they've been disappointed so many times before with other help systems.
In fact, today we had a tech support person bring us a printed copy of a web page with a topic that he said should go in the LabVIEW Help because it was so useful to the customer. Turns out, he'd printed a topic from the LabVIEW Help we just recently posted to the Web!
Funny. Frustrating. The incident might say more about people's comfort level with the Web as the ultimate documentation resource than about their confidence in the LabVIEW Help. Then again, it might also show that we need to continue marketing our own Help - even within the company.
I'd be curious to read more examples of great online help. Suggestions, anyone? I've got a list as long as my arm with bad examples...
Subscribe to:
Posts (Atom)