Decoding the Basis of Technical Writing

Hey guys! I’m back to start from where I left. So, my last blog was all about intricacies of a mixed profile (Technical Writer cum Business Analyst). This write-up will make you dive deep into basics of technical writing as an analyst. Here, I want to discriminate writing and technical writing basics.

Writing Basics:

• Clear: Convey the message writer wants to give
• Unambiguous: Every sentence must convey single meaning
• Complete: Your document is complete with 5 W’s; What and Why and When
  And How (and sometimes the H) and Where and Who

Technical Writing Basics:

Obviously we need above super-set of attributes but our motive changes here, let’s see how:

• Users judge the quality of product, s/w based on the quality of documentation.
• Quality states the measure of accuracy (absence of errors), like typos, spellings, punctuation, incorrect data.
• Usability defines clear and accurate information.
• Is the content standalone?
• Can someone use it?
• Do you understand what you are writing?
• Is the information misleading or ambiguous?

What you need to do?

• Target audience is very important
• Think about the way people need information(text, non-text)
• Provide structure to documents, use headings, bullets, Include tables, Steps, Flowcharts for decision-making and branching options in a process.
• Ask open-ended questions to get the right information from the SME.
• Be consistent
  • Decide how to refer to the product.
  • Consider interface elements and actions
  • Don’t forgot styles, fonts, and layouts
  • Use a style sheet.
• Illustrate
  • Use appropriate graphic types
  • Use callous or annotations to focus attention.
  • Use various image views like exploded view, isometric view, and so on.
  • Place the graphic after the content.

As a business Analyst:

Business analyst keep track of each phase during Software Development Life Cycle and with each phase comes documentation. Verbal, email or any communication plays a vital role in success of a project so, these needs to be documented for a clear view.

• Finding hidden hazards through scenarios.
• Use a ranking mechanism to differentiate types of severities (important, very important, urgent)
• Dig out the scope, capabilities, benefits, data, validation of the software

Once you follow the above guidelines and done with your document, keep track of it through document development life cycle.

Next time we will discuss about n types of documents involved in business analyst profile.