Search results

Writing in the Trenches Versus Writing on the Sidelines

by Tom Johnson on Oct 27, 2012
categories: technical-writing

One of the reasons my blog has been successful among technical writers is because I'm in a technical writer in the trenches rather than on the sidelines. In contrast, many other people in the field of tech comm writing blogs are sales engineers, consultants, marketers, or c-level executives.

If there's one truism about writing that seems to work universally, it's this: write about what you know. When you're immersed in the environment first hand, working directly with the tools, processes, challenges, and dealing with all the issues that go along with your tech writer role, it's a lot easier to write about real technical writing topics that connect with other technical writers.

Hardly a day goes by that, as a technical writer, I don't experience something worth writing about. Sometimes it's a little experience that I'm curious to explore in more depth. Other times it's the big issues that have my head spinning. Either way, experience works as the catalyst for writing.

This setup is convenient for me, but what if you're writing for your company, and your role varies widely from your audience's role? Let's say you're writing for business entrepreneurs, but you personally have no interest in business entrepreneurship.  Or let's say you're writing for doctors, but you personally aren't a doctor nor do you have much passion for medicine.

Setting aside roles, what if you don't use your company's products? Maybe you sell million dollar storage array systems for network engineers. Maybe you sell financial software for series 7 analysts. Or PCI audit solutions or some other product that you don't use.

It's rare that company employees regularly use the products they sell. Without using the product, how do you write about these products so that you can create real content that speaks to real users?

Use Your Products If You Can

If you have access to use your company's products in real situations, this is the first step to take. This situation better fits tangible products that people buy and sell online -- mountain bikes, clothing and apparel, photography gear, or some other physical product. You can go out of your way to try them out, testing them out in situations.  In the IT field, using your own products is called "eating your own dog food."

I'm in a fortunate situation to eat my own dog food. For example, I recently began using our Gospel Library app to read scriptures digitally, rather than reading traditional paper scriptures. Using the product has opened my eyes to all kinds of topics and issues to write about.

Experience Your Product Through Other Users

Let's say that your product really isn't something you can use. In this case, you can try to use it through the eyes of another person. In fact, even if you do use the product yourself, you'll still need to immerse yourself in the experiences of others, since one person's experience can never generalize to everyone else's experience.

When you gather experiences and feedback from other users, you probably won't feel the same sense or urgency and passion behind the issues, but with a bit of imagination and empathy, it can be enough to write about the topic credibly and intelligently.

To see the product through your users' eyes, first, you must regularly read and review their feedback. I gather feedback from my users through various channels: forum posts, feedback links, support  center calls, social media posts, online metrics, internal discussions, and more.

Setting aside time to actually read the feedback is not something that comes easy. It's easy to ignore this stream of information, but without reading it, I won't know get the users' perspective.

By regularly reviewing this information, I can identify trends that represent real issues users are having. For example, we just had a big conference, and many users are having trouble downloading the recordings. I hadn't tried downloading these recordings myself, but now that I see the trending issue, it gives me a relevant issue to address.

Interact with Users Like an Ethnographer

Another way to see your products as your users see them is to immerse yourself in your users' environment. If you can be on-site as an observer, in their same environment, the knowledge you gain is enlightening.

I don't interact directly with users nearly enough. You often have to go out of your way to interact with users. But when I have interacted, usually through training or usability sessions, it helps me see the product in an entirely new light.

For example, one time I wrote help for a product designed for older people. When I saw an 80-year-old man wearing thick glasses struggle to click a small calendar button because his hand was too shaky, I realized that I hadn't really understood who I was writing for. Far from computer savvy, my audience needed things really simple and BIG.

One of my favorite authors is Ted Conover. He takes an ethnographic approach to his nonfiction writing. If he wants to write about what it's like to be a prison guard at Sing-Sing, he becomes a prison guard at Sing-Sing. If he wants to write about riding trains with hobos, he rides trains with hobos for a summer. If he wants to write about the upper class living in Aspen, Colorado, he becomes a food caterer for rich people and lives among them. Conover's books are fascinating, and I don't see how he could possibly write them without total immersion into these situations.

Concluding Thoughts

Whatever type of content we write, experience with the product as an actual user plays a huge role in our ability to narrow in on timely, relevant issues. As such, it's always a best practice to use the product as much as possible. If that isn't possible, you must immerse yourself in feedback and situations where you can observe users in order to gather feedback.

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.