User Assistance

On-line and Application Help authored and customised to your specific application requirements in multiple formats, such as: HTML, CHM, Mobile and PDF.

Rapid eLearning

Tutorials - Content authoring of interactive software simulation and video tutorials customised for your client training.

Documentation

Update, transform and enhance your existing documentation into formats, such as Wikis, for online access by shareholders, employees, suppliers and customers.

Testimonial

“Alan and I recently worked on a project together. During this period he paid particular attention to the finer detail and was never happy unless the product had the right feel and met with his high standards. He was never short of ideas to overcome a problem.”

Keith Andrew Customs Coaching

 

Reasons to use a Technical Writer

PDFPrintE-mail
Time saving for key personnel
You probably realise that your designers, software developers, marketing people or other key individuals who are responsible for writing your support documentation, would be better off employed doing their proper activities like designing, developing software or making sales?
 
There are major disadvantages to assigning skilled people with tasks as time-consuming as documentation which in most cases is out of their comfort and skill zone.
  • They generally resent doing it.
  • They may not be very good at it (after all, it's not usually what they're trained for).
  • It holds up progress by diverting their attention from the tasks they do best.
  • They frequently struggle to have the documentation ready.
 
This approach may be to difficult to define in your balance sheet, but in terms of lost time and focus, it can prove to be an expensive option. 
 
Our primary objective is to provide the best possible documentation with the least demand on your resources.
You will be surprised at just how little of their time we need!
 
Typically, our only requirements are:
  • an initial walkthrough – similar in level to a demonstration that you might provide to a prospective client, but dealing with some behind-the-scenes detail. These walk-throughs are normally recorded for later transcription to a document which is far more effective than making notes.
  • access to working software or hardware – neither of which need to be in their finished state, as we routinely document systems while still in development. Indeed, this is usually the best approach since it means that the system and its documentation can be ready for release at the same time.
  • periodic access to relevant members of your staff throughout the project to answer specific queries.
 
Any existing documentation that may be available, such as user requirement and design specifications, are very useful but not essential.