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.
Your history sounds a lot like mine. And if you're lucky, you'll get to
push beyond interface design.
I would just add a couple of other points that I have often added to similar
threads in the past:
Make yourself a part of the development team. Your deliverables and
milestones should be a part of any project planning that goes on. I do not
believe in ivory tower documentation--those that think you must follow some
set of rules especially for documentation that do not provide interaction
with development, QA and implementation. Such efforts tend to isolate you
further. If the team has status meetings, go to them. You may raise some
eyebrows at first, but they'll start figuring out that you're more than a
font fondler pretty quickly.
Offer to take on additional responsibilities. I offered to write the
functional specifications where the UI was defined, simply because no one
really had the time to devote and I enjoy doing it. Not only does that give
you input on the UI, it gives you input on functionality, and an amazing
head start when it comes time to write. And an impressive line on your
resume for business analysis. This is especially true for those that worry
about the lack of specs in their development environment. Don't complain
about it... Fix it. Offer to write the specs, and you'll soon be seen as the
miracle worker who makes life better for everyone.
Test the product while in development. I get builds at the same time QA
does, and frequently find bugs before they do. In return, they test the
help files before the whole shooting match goes to packaging and release.
They think of the help as integral to the product, and they write bugs on it
as well. It's way cool.
My main soap box point when this issue resurfaces is simple: documentation
is NOT separate from the product, it's part of the product and until you
treat it that way, nobody else will. You may have to find a champion, you
may be able to find your way in on your own (I talk loudly, but I back it up
with high quality results, and they know it), but if you work hard and work
smart you'll be as integral to development as the best programmer around.
Documentation, in whatever format, is part of your branding (and yes, that
means marketing) efforts, it's part of your company image, and it's part of
your commitment to support. It's not trivial, and it's certainly not
separate. To do it well you need to be one part business analyst, one part
QA, several parts industry and technical expert, and an overall good
communicator. Forget the ivory tower, get down there in the trenches!
I think that ends the quarterly soapbox report :)
Regards
Connie P. Giordano
Senior Technical Writer
Advisor Technology Services
A Fidelity Investments Company
704-330-2069 (w)
704-330-2350 (f)
704-957-8450 (c)
connie -dot- giordano -at- fmr -dot- com
"Pray that there's intelligent life somewhere up in space, 'cause I'm afraid
that we've been cheated here on Earth" - Clint Black "Galaxy Song"
-----Original Message-----
From: Daniel_Hall -at- trendmicro -dot- com [mailto:Daniel_Hall -at- trendmicro -dot- com]
Sent: Wednesday, September 24, 2003 2:48 PM
To: TECHWR-L
Subject: RE: participating in interface design
I'm in a similar situation to Geoff's - the engineers actually ask for input
for both wording and usability in the UI. I think there are several reasons
for this:
1) Many of our developers are not native English speakers and they know that
what they write in English may not be grammatically correct or concise. They
are willing to ask for help (Most native speakers are less willing, IME)
2) I have provided useful/valuable input in the past and that carries weight
when they are deciding who needs to have input.
3) The engineers recognize that working together during implementation
(getting my input early) helps them avoid the need to change things later.
I also have another advantage - as a trusted member of the development team,
I have access to the source tree from which our product is built. When I
find a purely textual error, I open the source file and edit the text
directly, and then check it back in. This willingness to "get my hands
dirty" (as one engineer put it) has gone a long way towards building
credibility with them. Exercising caution (so that I've never introduced
errors that have broken the build) has also helped
:-)
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.
