Technical Documentation

I am a freelance technical documentation consultant and can help anyone involved in developing technical documentation by promoting a clear and coherent process in developing good documentation. I have extensive experience producing technical and scientific documentation as well as technical training material for academic scientists. I have worked in the high performance computing and computational science discipline for nearly 20 years and have written numerous internal reports and technical documentation.

Technical documentation can be difficult to produce as it is attempting to convey complex information to an audience that may not necessarily be technically knowledgeable in the domain of interest. To ensure the audience make full use of the technical product or service, the documentation will need to properly peer-reviewed and tested by skilled technical writers who are not involved in developing the product or service so that they can maintain a good level of impartiality and independence.

I offer the following services:

  • Technical documentation consulting to help companies structure and review their documentation;
  • Technical documentation proofreading;
  • Technical documentation testing. This short article highlights the importance of testing: Validate Your Content: Quality Assurance Testing for Documentation;
  • Proofreading marketing material;
  • Proofreading academic papers in preparation for submission to journals, which is charged at an academic rate;
  • Proofreading BSc, MSc and PhD theses, which are charged at a student rate.

For any queries, I can be reached at wadud.miah@gmail.com or +447905 755604 (UK mobile). Further information on the technical documentation service I am offering can be found below.

I can help technical document writers ensure that their documentation is:

  1. Easy to use:
    • Task orientation – focuses on the task that users want to complete;
    • Accuracy – ensure the information is accurate;
    • Completeness – ensure that all relevant information is included.
  2. Easy to understand:
    • Clarity – technical information is clearly written and conveyed using good English;
    • Concrete – examples are provided to help users understand the content;
    • Style – a good style guide is adopted that is suited to technical documentation.
  3. Easy to find:
    • Organisation – content is properly organised so that users can find relevant information;
    • Retrievability – content can be easily searched;
    • Visually effective – the content is visually pleasing and information is not cluttered.

The process that I am promoting is:

  1. Plan:
    • Define scope and stakeholders;
    • Develop a project plan with milestones;
  2. Structure:
    • Create table of contents;
  3. Write:
    • Write first draft;
    • Review draft with subject matter experts;
  4. Review:
    • Review with stakeholders;
    • Review with consultants to ensure the documentation is easy to use, easy to understand and easy to find as listed in the previous list.
  5. Publish:
    • Check into a document control system;
    • Publish documentation.

I can help in the Structure and Review phase of the technical documentation life cycle.

Technical Communication User’s Hierarchy of Needs

Much like Maslow’s hierarchy of needs, technical communication users also have hierarchy of needs which was brilliantly put by Ellis Pratt of Cherryleaf:

hierarchy-pyramid

The different levels of the above hierarchy map to the following products:

hierarchy-deliverables

As can be seen from the above list, there are a number of requirements for good technical documentation and the dependencies are shown in the pyramid of needs. A thorough description of this hierarchy can be found in the article: A Technical Communication User’s Hierarchy of Needs.