The ideal user's guide is no user's guide

What makes a good software user's guide?

The standard answer would be a guide organized by tasks, written in small chunks of text, liberal doses of graphics, and a comprehensive index. Sprinkle in a troubleshooting FAQ and you've got yourself a manual.

But wouldn't it be nice if the software you were documenting was so simple that it didn't require a user's guide, maybe just a simple "getting started" guide? Isn't the fact that a user's guide is needed at all an indication that the software is not easy to use?

Unless your organization has a dedicated Human Factors group, we technical writers need to be in on the initial requirements gathering process, talking to the users and finding out what they need the software to do. This is happening more often these days, with organizations like the STC building awareness of our value in the IT industry, and individual technical writers raising their hands and proactively asking to attend customer requirements meetings.

Once we have the users' requirements, we then need to advocate for them throughout the development cycle, hounding developers (in diplomatic ways, of course!) to err on the side of simplicity. Even large systems that track financial services or retail merchandising could benefit from a little simplicity and streamlining.

Because if we don't advocate for the user, then it will be up to us to write that 400-page manual.