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.
Subject:Contributing to the UI From:Jean Weber <jean_weber -at- COMPUSERVE -dot- COM> Date:Sat, 8 Mar 1997 15:13:12 -0500
Rikki Nyman asked,
" ... the programmers
bristle when they think you are questioning their UI design. My
question is, how can I guide them effectively in at least correcting
some of the more glaring oddities without alienating them?"
I was involved in a project where we writers (and editor) attempted to
improve the UI, but were ignored ("it's too late to do anything about it").
Fortunately a module was usability tested. Guess what? Most of the problems
(and complaints) that rose from the test were related to things the writers
had suggested should be changed. They were changed. The next release, the
writers were invited to participate in the design, and the release after
that, we were on the sign-off sheet for the UI design.
You always have to show the other person what's in it for them. My approach
is usually to siddle up to the project manager, or the head programmer, or
even the individual programmers (whichever is appropriate) and gently
suggest that if I "edit" their UI a bit, THEY will look better.
Often the initial reaction is suspicion, but if you genuinely want to help,
most people will eventually let you. Some will even be deeply relieved
(whether they admit it or not). Some will give you credit. Others might let
you help, but not want to give you any credit, and they'll make sure you
take the blame for any problems. (Since documentation often takes the blame
for problems in the product, this shouldn't be anything new to writers.)
Some will be so offended that they'll get really viscious. The last group
cannot be taught or helped; all you can do is put up with it or leave. All
the others can be taught.
If you are accused of having ulterior motives, say, "Sure I do. I want to
have an easier job of writing the documentation. The better the UI is, the
less I have to explain it." Project managers (or whoever is responsible
for containing costs) can be won over by extending that to include, "And
less work for me means the project's costs are less. If both the UI and the
documentation is improved, support and help desk costs should also be
less." (The last may not matter to the project manager, if support costs
come out of someone else's budget.)
I would certainly attempt to educate management to include a writer on the
design team. That assumes, of course, that the software is actually
designed!
Jean Weber
Technical Writer, Editor and Publishing Consultant
Sydney, Australia
jean_weber -at- compuserve -dot- com
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
