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.
Esther Wheeler (ewheeler -at- azure-tech -dot- com) writes:
>Many of us do document less-than-ideal products, in the best cases
>simply for evaluation (alpha and beta releases). I'd like to hear
>how other writers in this situation push back on engineering
>before these unsightly products get to release. What approach
>gets you the best results?
I have sometimes gotten results by presenting "for technical review" a draft
of the section documenting the less-than-ideal features which I hope to see
changed. One might even slant the draft (not the docs for release) to
ignore any workarounds, make the problems blatant, and provoke the question
"Why doesn't it work this way instead?"
Another approach that has worked sometimes is vividly describing the user
difficulties, and suggesting we in development fix it our way now rather
than waiting until the Powers That Be (marketing, upper management, etc.)
redesign it themselves. The implication is that the change is probably
inevitable, but our redesign is more likely to be properly integrated into
the product, easier to do, easier to maintain, etc.
