When I was documenting a new refactoring plugin for Vim, I checked out the Vim web site, and came across this blasphemy:
Vim isn’t an editor designed to hold its users’ hands. It is a tool, the use of which must be learned.
Later, someone sent me this beauty, from Elitist Jerks:
Stop being lazy and read.
Are users lazy? Do they expect hand-holding? Do they expect one button and no manual?
Or is this more true to life?
In the end, it probably comes down to this: Make tools usable. Then technical communicators can spend more time creating truly helpful help, and less time explaining a bad UI.
If our goal as communicators is not just great help, but a great product, Agile makes more sense than ever. If we want our usability suggestions to be implemented, we need to get developers’ attention while they’re working on that feature. Find the rough edges that would require a lot of splainy-splainy, request a change, and then rejoice that we don’t need to explain what’s now obvious. Sometimes it’s hard for me to decide what’s a rough edge. Would my audience of developers find this as confusing as I do? But I’m learning to trust my gut.
At the same time, though I appreciate the benefits of Agile, I’ve started to worry less about the help being “done” at the end of an iteration; instead, I want to make sure I understand a feature well enough before the end of the iteration to suggest design changes and know what help will be required.