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.
Suzette described a situation with a developer who was less than interested
in hearing her feedback about his UI design...
Given that it sounds like this developer is not interested in changing his
design based on your reactions, I suggest you document *exactly* what s/he
has created. If you do a credible job, your User Guide or help system will
reflect the interface, its complexity, and the fact that many aspects are
non-standard.
That way, you will have accepted what the developer built, and as people
read it, they can say "wait a minute, does it really work *that* way?" By
exposing the structure of the application, you give your users a chance to
comment as well, and also to have half a chance of figuring it out with
less confusion than you had.
The hazard of this approach, I'll admit, is that some people will blame the
document for making the application hard to use, rather than seeing that
all you wrote is what you actually have to do to make it work in any useful
way.
