The help system or CSH topics – which is more important?

Where I work we have a core system upon which software "solutions" are built. The core system was built as a product in its own right but functions as the platform that is used to build these solutions - each of which serves a different purpose for a different type of user doing a different job.

So we have a legacy help system (which I created about six years ago and the content of which is mainly still my work) which is supplemented by context-sensitive help (CSH) for each solution. One of my tasks for the coming months is to make sure that the topics in the core help system work equally well in the context of each solution. The tricky bit is that these solutions are designed to be integrated, so while one customer may only have Solution B, another customer may have Solutions A, B and C all integrated together within the same system, with some of their users only getting access to one solution, but others seeing all three. And the help topics need to allow for this without: a) requiring any coding (because no development effort is available for user assistance) or b) turning into a maintenance nightmare by creating a web of conditional behaviour.

But thinking about how this might be done led me to consider how important this core help system is. And in my opinion, from the user's point of view, the importance of assistance is largely measured in relation to how immediate it is. This is, of course, balanced by how useful it is and the nature of the assistance they need, but number of clicks away from where I am now is a big factor. So it shapes up like so:

1. What's in the user interface (labelling and messages).

2. What the user sees first when they click Help.

3. What they see next.

4. If they're still looking, what they see next.

Tech writers don't get involved enough with point 1 (Graham and I were just discussing this yesterday). It's something we could really help out with but are rarely asked to contribute to. Now I'm not saying that a good tech writer is necessarily a good usability analyst, but I know from experience that we're often more sensitive to usability than the programmers who often get left to write user interface text.

Point 2 might be a CSH topic with the information the user needs, but sometimes (e.g. when there are lots of things you might be doing on that particular dialog box or form) it's not possible to cover all the bases in a short, snappy help topic, so you need to use a landing page topic with questions that will branch out into information topics.

Point 3 is either a topic within the help system (if 2 was a CSH topic) or a CSH topic (if 2 was a landing page).

Point 4  is a topic within the help system, and because it's so far removed from what the user was looking at, he/she may never get here. Help is all about getting an answer and getting on with what you were doing as quickly as possible. Nobody but a really desperate user - or a tech writer - browses a help system.

So I think we need to really focus our attention on the context-sensitive help: the CSH information topics and any landing page topics we need to use. Yes, we should try to make the core help system as comprehensive in its coverage as we think genuinely represents value for money and a good use of our time/effort, but I believe we should only do this after we're happy that we've made a really good job of the CSH.

I guess it's the tyranny of the majority again. We're spending a lot of effort crafting really well targeted, clear, concise and correct topics for the majority of users who never get past one or maybe two clicks into the help. And inevitably, in doing so, we're going to have to sacrifice some of the requirements of the minority of users who occasionally go looking for information in the core help system. For them, I believe, we should concentrate in getting the information in there for them. It might not be pretty. We might not have spent so long crafting it to be easy to digest. But it's better to have information in there that you have to read twice to work out what it means, than not to have the information in there at all. We can comfort ourselves, perhaps, with the thought that users who are prepared to go digging in the help system may be more capable of understanding information that might be a little bit raw.