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.
While there has been several posts on this subject, I thought I'd add my
quarters worth.
I run across this all the time. Programmer's develop a user
interface/program flow that makes perfect sense to them, but confusing for
others. In many cases, it's not that the UI is bad, but it's so obvious that
a small change could greatly improve it. Some of the younger, newer
programmers don't seem to have as much of a problem accepting input from
tech writers, while the older ones do. Having said that, it's really an
individual thing. Some programmers just don't want to listen, because they
are the "expert." Since I've done development work and been on the other
side, I know programmers better than some tech writers would ever want to.
On the whole, they are OK folks; they just have too much of their egos tied
up in their work at times.
This is what I do:
I document everything I find "wrong" with the application. Sometimes these
are suggestions on the UI, other times just out-and-out bugs. When starting
a project, I make it very clear that this is what I do, and I consider it
part of my job. It sets the stage. If a programmer rejects this, I find
his/her boss.
If working with a new programmer, I feed him/her with small bits to test the
waters. Many times, when they see the benefits of making some of my changes,
they will be open to more. Small steps, or as is called in instructional
psychology, sucessive approximations...
My stance is that if the UI and application are created with the user in
mind and are as simple as possible to use, this reduces the amount of
documentation and training needed. This reduces costs. Programmers are so
overpaid now, that any reduction in development cost should be welcomed.
Sometimes I've found it useful, especially in developing in-house
applications, to find an advocate user during the beta period. If the
programmer won't listen to a tech writer, maybe he/she will listen to an
actual end user.
There are no simple solutions, but anger is not one of them. I do understand
the frustration. Pick your battles. You will not win them all.
The basic line here is to not only document what works, but to document in
detail what doesn't.
Steve Taylor
(214) 853-7182
Dallas, TX
----------------------------------------------------------------
I CAN is greater than IQ
----------------------------------------------------------------
