Technical Writers are primarily writers and writing is their profession. The source of what technical writers write usually comes from experts who are the intellectual owners of a product or a process. What this means is that technical writers must practice and constantly improve the skill of gathering technical information and processes flows from the subject matter experts. This article talks in brief of some of the aspects of gathering information.

Have You Experienced This? The Short Term Memory Loss

I met up with Dave at 2 PM yesterday, I wanted to understand the new product that he is developing (let’s say product X). I am responsible for creating documentation for product X. So we spent 45 minutes talking about the purpose of the product, about what kind of industry it is used in, what problem it solves.

Dave also showed me a demo of the product, explaining in detail all the steps involved in entering the input data till generating the final report. I thanked him. Came back to my desk. My phone rang, and just as the call ended, I realized that my mind was completely blank. I forgot most of what Dave had told me, not more than 30 minutes ago.

Gathering Information In A Way That It Remains With You

The trouble with being the guy responsible for documentation of a product, is that their is no documentation that you can refer to. Yes, you may have the SRS document, you may have the introduction PPT file that was used to pitch the idea of the product before it was allowed to be developed, but these kind of documents are usually out dated by the time the product gets under active development.

This lack of up to date documentation means that, as a technical writer, it is your job to elicit the information from the people who know the most about it – the Product Manager, the Developer, the Marketing Manager and others.

The information that they can provide you moght be in the form of verbal explanation, a demo of the software, more verbal explanation and verbal answers to your questions. That means there is going to a ton of information that is going to enter your ear and hopefully through your fingers gets into the user guides, tutorials, FAQs, etc.

Documenting Processes, Concepts and Workflows

Your only recourse to understanding and retaining what you hear and see in during these information gathering interviews is to use the tools that Business Analysts (BAs) use in their work. In business analysis terminology it is called Requirements Gathering.

Among the Tools that BAs commonly use are, the ones that are useful for technical writers are:

• Process Models
• Use Cases and User Stories
• Story Boards

Process Models

Every software is solving a problem, and every software takes the user through steps that lead from definition of the problem and to the solution to the problem. This is means there is a process involved. Some steps in the process might consume more time than others, but it is a process none-the-less.

So one of the fundamental ways the working of the software can be understood and documented, is using a Process Model. A process model is a visual representation of the process using what is know as the Business Process Model Notation (BPMN). The BPMN gives a lot of options to technical writers to visually represent the workflow of a software. This visual workflow can act as a reference for the user of the software, as well for the technical writer to ensure that the documentation covers all aspects of the process.

Either during or immediately after an interview with the Subject Matter Expert, if you can create the Process Model for the software, you would have done a great service to yourself. This process model can then be your guiding map in obtaining and writing detailed information about each steps of the process model.

Use Cases and User Stories

Use cases and user stories are most likely to be found in the SRS document of the software. These two tools are used extensively by product managers and software developers themselved to architect the product that you may be documenting.

Use cases can be of great help in organizing the documentation, in deciding the order of presenting the content in the product help. If a user is going to use the product in a certain way, then it is most likely that he will need the relevant information in the same order.

Irrespective of how a user navigates through the documentation, the user cases and user stories can help you as a technical writer, to make sense of the documentation and ensure that there is comprehensive coverage of information that is required by the users of the software.

Story Boards

Story boards are an excellent way of deciding what kind of contextual help a user will need, when going through the workflow that the software takes the user through. Story boards help in giving a clear picture to the technical writer, the steps that a user might have finished earlier and the immediate next steps that a user needs to complete to move forward.

Thus, story boards can help you to filter out content, that is not relevant to the user at any particular stage and present only that information which is. A story board created collaboratively with the developers and product managers, can get everybody on the same page about the content that is relevant at each stage and might even reduce the cycle time during review and correction phase of the documentation.

What Happened to Product X?

So Dave being the nice guy that he is, was kind enough to take me through the demo once more, and this time I used a process model to create a snap shot of the software’s workflow. I then used this process model to guide me through writing the documentation.

**Useful Link: **
– Requirements Gathering Tools