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.
Sean Hower, responding to my comment that "I'm fortunate to have acquired
enough expertise to earn the respect of my developers, to the point that now
they often bring me into the design phase at the start...", wondered: <<How
do you get the developers to listen to your input in the first place?>>
I started with baby steps. For example, they use external "language" files
to hold all the text in the interface, and rather than making them fix all
the typos and mistranslations (our software comes in English and French
flavors), I edited the files in Word using revision tracking. That let them
accept all the revisions quickly without any retyping, reconcile any
differences I detected between languages, and so on.
Next, I offered to help them fit text into a tight space on the screen where
they were having trouble describing a field and knew that their solutions
weren't satisfying even them. In the course of doing this, I also provided
some interface suggestions. Once, I even used my ancient knowledge of
programming to suggest a simpler interface that also (fortunately) made
their job maintaining the software much easier. Another difference is that I
have really good credit with the researchers whose work I edit, so when they
propose new software, they're quite willing to listen to my boss' suggestion
to include me in the early design meetings.
Of course, Marc and Joe are both really good guys and open to suggestions.
YMMV. But in each case, note that I offered a way to make someone's life
easier rather than acting as a critic (thereby inherently trying to make
their efforts at interface design look foolish). Moreover, I discuss changes
rather than impose them (which I don't have authority to do anyway), and am
happy to brainstorm solutions rather than clinging desperately to my own
ideas. All of these things contribute to making them more open to listening
rather than growing defensive, and save them time rather than costing them
time.
<<I make suggestions when I see room for modifications, or if something just
doesn't quite fit, logically or otherwise. I am very nice about it too,
careful not to step on toes. But the results seem hit and miss. Either they
disagreed, or they simply forgot..>>
There's no guarantee of success, even if you make your sales pitch clearly
and convincingly, and that's particularly true if your guys are at their
wits' end trying to keep up with insane release schedules. In that case, all
you can do is try to demonstrate how working with you saves them more time
than working alone. Then, you can count on human nature to make your case
for you.
Moreover, as you note, people are human, and in the rush to meet a deadline,
often forget to include you in their plans. I've just recently input a batch
of help updates for one product based on a clearly spelled-out list of
changes provided by one programmer before the upcoming release, but in
reviewing these changes, discovered a batch of interface updates that were
done over the past year without ever notifying me. So my job next week will
be to compare the docs line by line against the revised interface to avoid
any embarrassments. You win some, you lose some.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
(try ghart -at- videotron -dot- ca if you get no response)
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"Wisdom is one of the few things that look bigger the further away it
is."--Terry Pratchett
NEED TO PUBLISH YOUR FRAMEMAKER CONTENT ONLINE?
?Mustang? (code name) is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to Web, intranets, and online Help.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! See a live demo that
will take your breath away: http://www.ehelp.com/techwr-l3
---
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.
