Chapter 7: The Extended Interface

The "extended interface" goes beyond the system's basic controls and feedback to include manuals, on-line help, training packages, and customer support. These are all resources that users rely on to accomplish tasks with a system.

How important is the extended interface? Isn't it true that "nobody reads manuals?" On the contrary, a survey we did recently showed that users in all kinds of jobs, from secretaries to scientists to programmers, will turn to external information sources when they don't know how to do something with a computer system. The source they turn to varies: it may be the manual, it may be the local system support people, it may be a phone support line. But users almost never know everything there is to know about the applications they use, and when they need to do something new, they look to the extended interface for help. (For details of the survey see Rieman, J. "The diary study: A workplace-oriented tool to guide laboratory studies," Proc. InterCHI'93 Conference on Human Factors in Computer Systems. New York: ACM, 1993. pp.321-326.)

Of course, the usefulness of external support varies, not only with the individual but also with the situation. For a walk-up-and use system, such as an information kiosk in a museum or a flight-insurance sales machine in an airport, the on-line interface is the whole ball game. But for a complex application aimed at a professional market, such as Mathematica or a sophisticated desk-top publishing system, external resources will be important while users are first learning the package, and they will continue to be important as a reference to seldom-used functions. In short, the use and importance of the extended interface depends on the task and the user. To accommodate this dependency, the development of the extended interface should be integrated into the task-centered design process.

This integrated design approach should begin with your very first interactions with users. You should be on the lookout for situations where manuals or other external resources would be used, as well as for situations where that kind of support would be inappropriate. Those observations will give you the background needed to rough out the design, imagining task scenarios in which users will work with both the on-line system and external support. The techniques we've described for evaluating the system in the absence of users can also be applied to the entire system, especially to manuals and on- line help. Later in the design process, when you've built a prototype of the system and the external resources, task- centered user testing with the complete package can predict much more than testing in a barren, unsupported environment that most users will never encounter.

That said, we should raise a flag of caution:

           Don't rely on external support to

           make up for a bad on-line interface!

It's true that most users will look in a manual or ask for help if they can't figure out the system. But they don't especially want to do this, and it's not a very productive use of their time. Worse, there's a good chance that they won't find the answer they're looking for, for reasons we'll describe later in this chapter. So, you should strive for an interface that comes as close as possible to being walk-up- and-use, especially for the core functionality that's defined by your representative tasks. External support should be there as a fallback for users who stray from the common paths that you've tried to clearly define, and as a resource for users who are ready to uncover paths that you may have intentionally hidden from novices (such as macro packages or user-programmable options).

The rest of this chapter gives guidelines for some common forms of external support: manuals, training, etc. This is a traditional division, but it's not necessarily one you should adhere to. Once again, look at your users, look at the task, and determine what would be the best way to support the on- line interface.