You are here: Resources --> 2001 --> Sometimes you really can be too helpful
Vous êtes ici : Ressources --> 2001 --> Sometimes you really can be too helpful

Sometimes you really can be too helpful

by Geoff Hart

Previously published as: Hart, G. J. 2001. Sometimes you really can be too helpful. http://www.techwr-l.com/techwhirl/magazine/usersadvocate/usersadvocate_toohelpful.html

In my 27 August 1999 column for Computerworld Canada, I discussed how on-screen clues called “affordances” help the users of your software understand what’s required of them while they’re filling in forms, changing settings, or using any of the software’s other features. I also observed that since screen real estate is so cheap, "you can always use a second or third screen if you run out of space" on the first screen.

Marc Goodwin (Systems Coordinator, Bombardier Transport) disagreed, pointing out that “...one of the major complaints that our users have... is that ‘it takes too many screens’ to do things. We need to remember that most users will very quickly get used to their screens. The screen that started out very friendly with lots of instructions and hand holding will quickly become ‘too slow’. Within a week, the user would gladly trade the hand holding for more data on screen and faster input.”

Marc’s observation reflects a central axiom of information design: know your audience’s needs well enough that you understand how to meet those needs. Left unsaid in my original essay was how those needs gradually evolve over time, as today’s neophytes become tomorrow’s power users. This is why it’s so important to establish and maintain relationships with your audience: it gives you a handle on their changing needs so you can plan to continue meeting those needs. As Marc pointed out, sometimes you can be too helpful.

Yet even once the original users outgrow the training wheels you’ve provided, they’ll still occasionally encounter parts of the software they’ve never before used, and if your audience is growing, there will always be newcomers who can benefit from detailed help that would get in the way of the experts. Fortunately, you can meet both sets of needs by letting the users themselves decide how much help should appear on the screen. You’ll still have to add the basic affordances, but they can become simpler; for example, “Type your family name here:” might become “Family name:”

For those who need more than this, you can make more detailed help available at the wave of a mouse. For example, let users switch between terse and detailed help directly from the Help menu, or use Apple’s “balloon help” or Microsoft’s “tool tips” to explain icons and other parts of the interface whenever the cursor floats over the object in question. You can even add a button in each dialog box labeled “More help...” What’s wonderful about online help is how easily you can empower users by letting them choose the level of assistance appropriate for their current needs, whatever those needs might be.

Of course, if the developers of a product had to write the support code for these aids by themselves, creating a useful help system could become prohibitively time-consuming. Fortunately, modern operating systems such as Windows and the Mac OS do most of this work for you. In particular, they provide built-in access to “context-sensitive help”, which is the jargony way of saying that when users hit the Help key, they immediately see the online help for their current “context”, namely the specific field in which they’ve placed the cursor or the dialog box that’s currently open.

Even where the operating system doesn’t provide built-in support for context-sensitive help, or where you simply lack the time to master yet another programming language (that of the help system), you can achieve good results simply by adding a “Help” button to each dialog box, and link it directly to text stored within the program or in an external resource file. You’ll lose some of the benefits of a fully modern help system, but you’ll still let users choose their own level of help.

How do you let users switch between detailed and minimalist help without having to create two enitrely separate help systems? When you create help files, you define pointers (context IDs) to each topic, so that when users press the Help key, the programmers can instruct the software to use those pointers to jump to the right topic. To provide two levels of help information, the programmers need only create two pointers for each part of the interface for which you’ve provided help: one detailed, and one concise. All the programmers need to do is add a simple conditional statement to their code (in English: “If help chosen by user = detailed then jump to topic 10d; if not, jump to topic 10c”). We use the same trick in my employer’s current software to let users switch between English and French help files at the click of a button.

As with well-designed affordances, providing the right help in the right place lets users solve their problems quickly, and that means more satisfied users, and possibly even fewer technical support calls for your company to handle. Letting users choose their own level of help is another example of how working with your audience, recognizing that their needs change, and spending a little time thinking about how to accomodate those needs can make their lives easier.

©2004–2024 Geoffrey Hart. All rights reserved.