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: Why docs aren't tested From:WandaJane Phillips <wandajp -at- ANDYNE -dot- ON -dot- CA> Date:Mon, 15 Aug 1994 16:27:18 GMT
In both my last job and this job I am involved with developers. In my
last job the developers came to dread my knock, generally they were so
far behind that they didn't WANT to know what was wrong with what they
had done. And it was OFTEN wrong. I would interview them and use screen
sketches to envision the system and then write text. They would do a
_technical_ review of the text and give it a pass or fail grade. When
the system got to the stage where I could run it, we hit the biggest
disaster I could imagine -- they had no tracking methods, so I never
knew what version I was running, how recent, or how complete. I found
so many places where they had changed the functionality and not only
not told me, but had okayed text after the change without noting the
change!! I was ready to scream. The product was so far behind schedule
that I feared I would retire before release. I left before I became too
Here, I work with the developers before they begin to code, even before
the design is complete. I have a say in the design itself. We work it
out in an interesting cycle that is great for me but drives the other
writer bananas. Writer and developers meet, discuss the product, the
writer generates a document that says this is what the interface looks
like, this is the functionality, these are my questions. The developers
look the document over and all parties meet again. More discussions,
revisions, discussions, revisions. So, recently I was able to produce a
document for a product in alpha phase that matched the product. Nobody
was late, nobody was stressed out, and the process affected the
product. It was more usable earlier in the cycle. I was amazed. When I
ran into problems, the developers were open and interested, sometimes
because I was trying to do things that had never occurred to them. They
only once said _A user wouldn't try that_ because I responded by
telling them I AM A USER!!
The other writer wants a working version several months before the
release date. I tell this person they are barking mad. There is
resistance on the part of this writer and the others in the company
(other products) to writing WITH the developers. Some of it is because
they cannot connect with the developers and so, are not comfortable
displaying their ignorance.
We're introducing usability testing for the products and soon, the
documentation (our pilot project was with a product that NOBODY is
documenting), in my product group, the Quality Assurance person uses
the documentation as a part of the testing process. Elsewhere, some
other process is used. This development team is pretty amazing - in my
opinion, but then, I'm getting what I want out of it!! The other writer
for this product works in another department (Marketing) and finds the
whole working strategy in this group to be distressing and annoying.
Oh, and I'm considered an excellent member of the team because I can
break any software I touch. I'm ALWAYS finding bugs and limitations.
my dog is old, my cat wants out, and the bills are hidden in the top
drawer... there is nothing to steal