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.
>
> I plan to visit the user interface design team and educate them on the
> problems of identically-named controls when writing user documentation.
> Suggestions, anyone?
>
Yes. Don't "educate" them. Meet with them and learn from them their reasons
for making the design decisions they did. Then, when you understand the
software from the user's perspective, document it. Unless the design is "bad,"
from a user perspective, do what someone else suggested here -- take screen
captures. The only perspective worth anything to a company that wants to sell
software is the user's perspective. Our difficulties with documenting an
otherwise effective user interface are our problem, as another poster pointed
out. If, however, you believe the user interface is not the best, you can
diplomatically express that to the design people and explain why you think
that (offer an alternative, perhaps). But your needs are not important,
really. The user's needs are important. If that means identically named
controls, so be it.
I hope you'll report back here with the outcome, because I expect that a bunch
of people are all rooting for you!
