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.
--- Hanlie Pretorius <hpretorius -at- pnp -dot- co -dot- za> wrote:
>
> My question is this: how do you think I should deal with this? I've tried
> the positive criticism approach, the laissez-faire approach of accepting it
> as part of the imperfections in the universe but none of these prevent me
> from looking at my bag and considering the distance to the door every time
> one of these hideous monsters enter the world.
It's a very frustrating situation when you are documenting something that isn't
designed or implemented, or both, properly. I've been in many situations over
the years where I felt strongly that an interface needed to be 'fixed' in some
way. I've done what you've done: pointed out the problems users would have with
the current design/implementation. I've won a few battles; I've lost probably
more than I've won.
The bottom line is that I tell my developers what I find, how the documentation
will look if this implementation isn't fixed--what warnings, notes,
workarounds, etc. I'll have to document--and I've urged, sometimes strongly
<g>, that the 'whateveritis' be fixed. But if they won't (or can't) do it, I
document what the user/customer will see and do my best to help the user make
use of the system as it is.
I've found that I have to learn that I won't get everything the way I think it
should be. You can't become so wrapped up in fighting for what you think is
right in a design or implementation that you lose effectiveness on your team or
within your company.
If you can't do anything about the current release, lobby for changes in the
next release. If you can't effect changes in this product, lobby to be involved
earlier in the next product. You're much more likely to be heard (because there
is more time to be heard) in the design phase or even in the requirements phase
before the design phase.
You keep pitchin', but you accept the fact that you won't win every game. And
you work hard to make the documentation, over which you DO have more control,
good enough to overcome any shortcomings in that which the documentation is
about.
You just do the best you can.
=====
Tom Murrell
Lead Technical Writer
Alliance Data Systems
Columbus, Ohio mailto:tmurrell -at- columbus -dot- rr -dot- com
Personal Web Page - http://home.columbus.rr.com/murrell/
Page Last Updated 07/15/01
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
