Introducing Team Documentation!

  • 9 October 2020
  • 0 replies
  • 61 views

Badge +2

When asked what I do for a living, I instinctively answer, "I'm a writer." I usually get a surprised look, followed by asking what kind of novels I write. While I don't write novels, my work certainly involves telling a story. I'm also part of an extraordinary team of technical writers who share my passion and dedication, Team Documentation!

Technical writing is the ability to translate complex software features and instructions into content easily consumed by a targeted audience. We refer to this as persona-based writing. For example, a new user may need expanded notes that lets them know how a particular feature fits into the overall picture. On the opposite side, a seasoned developer wants the facts without all the extra explanation. Knowing who you are writing for is key to being an effective technical writer.

We wear many hats: storyteller, project manager, and quality assurance inspector, to name a few. And of course, we must have a deep appreciation for the product itself. Each of us on our team has a relationship with our product engineers and developers. It's often up to us to "pull" content from them since they are usually focused on developing features. We must know what questions to ask the subject experts and translate their answers into persona-based content. Ultimately, we want our customers to use our products quickly and confidently. 

Team Documentation writes much of the content you find on help.k2.com. We write and update user guides for all products and product versions. ICGs (Installation and Configuration Guides) are more advanced and target our customers with on-premises installations. We organize complex data into manageable tables and matrices, Knowledge Base articles, videos, and blogs. We write tutorials that provide detailed steps for building complete applications from start to finish. Our how-to articles explain single features quickly. 

Once we become aware of a new feature, we begin gathering information on what it does, the targeted release date, and the product involved. Documentation research often starts a year or more before the product hits the shelves. Because we need to have a thorough understanding of how the feature works, we often test the product during its pre-release life-cycle stages. We are quality assurance inspectors, where we provide feedback to our developers in the form of bug and user experience reports. 

Technical writers bridge the gap between product development and product use. Of course, there is a bit of 'geeky' in us too, and it's very satisfying to learn about new software features as they come to life. Ultimately, it is our dedication to our customers and the love of our product that makes us tick!


0 replies

Be the first to reply!

Reply