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 has been <<... documenting a Java system in development. I
started very enthusiastically, suggesting improvements to screen layouts,
pointing out (to the business analyst) inconsistencies in screen designs,
spelling errors (!) and so forth just to have my ideas squashed by the "we
don't have enough developers to spend on trivial things like that" excuse.>>
There really isn't much cure for this kind of attitude other than watching
the company go out of business because people can't use their software and
switch to something more usable. The only really effective way to make a
change of this nature is to get a manager higher up the chain of command to
recoil in horror at the miserable interface and insist that the developers
fix it. Of course, if you're the one who brings the problem to their
attention, then you're seen as playing political power games, and if the
developers find out, they're going to resent what you've done; that may
create worse problems than the current situation.
That being said, you might be wiser to figure out how to develop a more
mutually respectful relationship with the developers. First, you need to
clearly distinguish between two types of errors: (i) typos, blemishes, and
ugly designs that could certainly be improved, but that won't really stop
users from using the software, and (ii) actual usability problems that lead
to errors, lost time, and expensive calls to technical support. Much though
it hurts, you should start out by ignoring the first type of errors and
concentrate on the second type, since it's easier to convince developers to
fix things that are real problems. Fix only the really crucial stuff at
first. Once they've gotten used to fixing real problems based on your
feedback, you can slowly introduce the concept of fixing other things.
Second, you need to clearly identify why they won't make minor corrections;
you can't come up with an effective stragegy until you know those reasons.
For example, it's quite possible that they really don't have time to fix
minor things because the programmers are doing 80-hour work weeks to meet a
marketing deadline; that's going to make them both cranky and reluctant to
spend an extra few hours per week on your suggestions. If time's the
problem, sometimes you can offer to do the fixing for them; it's often easy
to explain to your manager that it's faster for you to fix an interface
problem than it is to spend hours writing around the problem. For example, I
now routinely edit the external language files that contain the text that
gets integrated with the software (as field labels, menu names, etc.). Since
these are just text files, I can edit them and return the corrected files to
the developers, who reintegrate them with the software during compilation.
They don't have to do a lick of work, I get my corrections done, and
everyone's happier.
<<Eventually I stopped spending time on pointing out errors I found but
every time a new screen comes out, I just want to scream with frustration at
the bad design. The usability of these screens is *terrible*.>>
If you really aren't respected enough by your colleagues to come to work
with a smile, you have only two choices: start over from scratch today and
try to earn enough respect that they pay attention to you (once you've got
it, they'll spend time working to implement your suggestions) or find
another job where you can develop a better working relationship with the
developers. The latter's far easier, but avoids the real problem, which is
learning how to work with difficult and demanding clients: the developers.
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"The most likely way for the world to be destroyed, most experts agree, is
by accident. That's where we come in; we're computer professionals. We cause
accidents."-- Nathaniel Borenstein
Planning to attend IPCC 01, October 24-27 in Santa Fe? Sign up by
October 3 and get a substantial discount! Program information,
online registration, and more on 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.
