TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: An Engineer has infected my young mind! From:"Christensen, Kent" <lkchris -at- sandia -dot- gov> To:"'TECHWR-L'" <TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM> Date:Fri, 19 May 2000 09:00:19 -0600
This is yet another example of why it's so important that the tech writer be
on board from the beginning of the software project. Being asked to write
the manual once the software is mostly or completely designed and written is
a formula for failure, as is apparent in this example. Once again: think of
the outline of the user manual (or the names of the chapters if you wish) as
the design brief for software development. The design brief comes first.
The design brief describes the users. The picture of the users evolves with
every design review or progress meeting. It would be good to understand all
this, and it's best understood if you were there. Since the tech writer
knows how to present information in an understandable way, the tech writer
can contribute to user interface design throughout the whole process. Every
project where a person uses the product is a communications project. Why
would you wait until the end to bring in another communications expert?
Make best use of all resources available. None of this helps in the current
situation, of course, but you have the opportunity for "lessons learned."
Also, there is no mention of online help in this thread.