A colleague has made me realize that user assistance writers are codependents of bad UI design. Because we explain how the UI really works, we somehow leave our developers and companies feeling like they're "covered" when the users have a bad experience.
We're not covered; the users still had the bad experience. It's just that we can apply the "nanny nanny boo boo, you should have read the manual" defense.
A simple example is the Delete button. Because of bad design practices, it has two meanings in many software applications: "Hasta la vista, baby" as in gone, gone, gone, and "Removed from here and put somewhere else in case you change your mind" as in the Recycle Bin. Because of that ambiguity, we had a discussion at work about the need to explain in the context sensitive help exactly which Delete we meant on a particular dialog box.
But why is the UI using the same word for two very different actions in the first place?
So here is my new challenge. What if Help quit explaining how to interact with the UI and quit telling the users how the system would respond? What if that became the burden of the UI itself to make interactions clear and outcomes predictable? Better labeling, embedded text, useful tool tips, etc.
What would technical communicators do? What would Help do?
For starters, technical communicators could help write UI text. Then we could reserve Help for scenario type of topics, ala how to achieve some business outcome using the product or encourage users to attempt complex tasks by demonstrating their value.
But we have to break out of our codependency first. Part of me likes to document the obvious because it's easy; part of me likes to compensate for bad design because it gives me instant "I add value" gratification.
Sometimes being part of the solution just makes us part of the problem.