Technical Writing: The Art of Translation

This entry was posted Tuesday, 1 September, 2009 at 12:46 pm

Kicking off our guest blog series on The Meerkat Blog is a fascinating piece from a technical writer, focusing on the intermediary role of tech writers in the tech industry.

____________________________________________________________________________________________________________________________________________

The Art of Translation

The art of translationOne of my standing jokes at work, and also one of my assets as a technical writer is that I am ESL — Engineering as a Second Language. As a technical writer I work closely with engineers and software developers and need to be able to speak their language and understand their unique way of seeing the world, but it’s also important that this remains a second language for me and not my primary means of communication. That’s because I don’t want to lose touch with my readers, who for the most part, do not have a lot of technical knowledge.

I see myself as an intermediary, a translator (of engineering-speak to plain English), and an advocate for the users — those poor unsuspecting people who find themselves with a new device or software application that they need to learn how to use.

I try to put myself in their place. If I had just bought this product, what would I want to use it for? What would I need to know about it to accomplish my goals? As well as thinking about my audience, I play the role of guinea pig. I try out the software or the gizmo I’m going to be writing about. I make note of where I get stuck or have questions. I try to stumble into as many pitfalls as I can. I go out of my way to make mistakes. There is nothing I won’t click just to see what happens!

I can afford to be more fearless than the average user because in cubicles just down the hall are the software developer who wrote the code and the engineer who designed the device. They can answer my questions, and if I get stuck, they can bail me out.

In an ideal world I would try out the product early enough in its development that my findings could be used to improve the product, but the more likely scenario is that by the time I’m involved, it’s too late in the development process to make changes. So I use my finding to provide the users with clear, easy-to-follow steps, advice on how to avoid the pitfalls, and suggestions for climbing out if they do fall in.

Along the way, I also talk to marketing experts, product managers, and technical support technicians, and work with graphic designers and technical illustrators. Clear, concise conversations with all these people are as much a part of my job as the actual writing.

It’s not a perfect science. Sometimes I get it wrong and sometimes it’s impossible to protect determined users from themselves. The challenge is to give the users at least a fighting chance to get it right and to increase the odds that they’ll have a successful and productive experience with the product.

About the Author:

Diane is a technical writer with 12 years experience working in the high-tech industry. She writes Quick Start Guides, User Guides, Online Help, and assorted other technical documents. She’s worked as a full-time employee and an independent contractor. Diane is addicted to high-tech, working with engineers, and writing.

No comments yet.

Leave a comment