The idea of not trying to guess what users are looking for in documentation has been bumping around in my head since the STC Conference. I was talking to my manager yesterday about altering my approach to help. So far, what I have done (at least in context-sensitive help situations) has been to think about the details of application screens—how to use the controls, where prepopulated data come from, what happens downstream, how to get displayed data changed—and provide information in those areas.

I don’t think this cuts it anymore. Why? It’s the crystal ball approach.

I think my approach needs to be to look at why a user may be clicking “Help” on a given screen and then provide information that addresses that motivation. I don’t think users open the help system to satisfy an idle curiosity. They don’t want to spend the time for that. When they open help, it’s to get a task done or solve problems.

But the key here is that unless I get real users’ input, I’ll just be guessing or “divining.” So my manager and I talked about sitting with people while they try the system out—similar to or in conjuction with usability testing—and find out why they click “Help.” Having them tell me how they think the help ought to be organized would eliminate a lot of guesswork. We’re hoping to get this kind of thing organized soon. It could change the way I look at my writing, probably only for the better.