We're humans first, beginners or experts second.
?span>Clifford Nass, CBC "Quirks and Quarks" radio program, 23 January 1994
Psychologist Clifford Nass's point is similar to one that this book makes: Our interface designs must begin by accommodating universal human frailties and exploiting universal human strengths. We must make sure that every detail of an interface matches both our cognitive capabilities and the demands of the task (not that those two objectives exhaust our concerns). His comment also reflects the common assumption that users can be grouped into two classes: beginners and experts, perhaps with a few temporarily in transition. This dichotomy is invalid. As a user of a complex system, you are neither a beginner nor an expert, and you cannot be placed on a single continuum between these two poles. You independently know or do not know each feature or each related set of features that work similarly to one another. You may know how to use many commands and features of a software package; you may even work with the package professionally, and people may seek your advice on using it. Yet you may not know how to use or even know about the existence of certain other commands or even whole categories of commands in that same package. For example, a user of a photo-processing application who produces only online images may never need, or even learn of, that same application's facility for doing color separations, a feature needed primarily by commercial printers.
Interface designers have tried various approaches to accommodate the premise that users can be separated into beginners and experts. Because this premise is false, the approaches have failed. Adaptive systems that shift automatically from beginner mode to expert mode when they judge that your competence has reached a certain level are a good example. If you are using such a system in beginner mode and it suddenly shifts into expert mode, you will find yourself on unfamiliar ground, at least with regard to a portion of the system. A system that shifts piecemeal, feature by feature, is no better. It will feel unstable and unsettling, because the habits that you were developing as a novice yesterday become useless when the feature shifts into expert mode today.
One web-based program I studied promoted you to expert status after you had used it once successfully. The program put you back into beginner mode when you had not used it for six months. Any such arbitrary schedule may not accord with a user's personal rate of learning and memory decay. If a program that promoted you switches to beginner mode after too short a time, you will feel annoyed at being forced to use the tedious beginner method. If the program does not switch back to beginner mode in time, you will be faced with features that you have forgotten how to use. Given present technology, a system cannot know when you have forgotten how to use a given feature, so it cannot know when it should shift back to beginner mode. A program that quizzed you from time to time to assess your level of expertise would be obnoxious.
Most attempts to make interfaces adaptive are ill-advised; whenever a system changes automatically, even if the change is as small as, say, a reordered set of items on a menu, your expectations are upset and your habituation is frustrated. (Microsoft features adaptive menus in its Windows 2000 operating system.) On the other hand, there is no theory that tells us that the same fixed interface cannot work well over the full span of a person's experience with it, from novice to old timer. It seems best not to have to shift paradigms during your use of a product, and no elaborate analysis is needed to reveal the advantage in having to learn only one interface to a task.
 Windows 2000 was a new product as this section was being written, and I was able to interview only a few users. A typical remark was, "Adaptive menus seemed like a cool idea, but the first time a menu changed on me, I found it upsetting. I don't like the idea any more."
It is easy to fall into the trap of designing different interfaces for different classes of users, because by doing so, you can make sweeping assumptions that simplify the design process. Few such assumptions are likely to be true of every user in any reasonably large class of users that you specify. The antidote is to view an interface not from the perspective of a class of users but rather through the eyes of an individual. Every person who uses software over a long period goes through a relatively brief period of learning for each feature or command and a far longer period of routine (and, we hope, automatic) use. We do need to design systems that are easy to learn and understand, but it is more important that we make sure that these systems can be efficiently used in the long run. The exceptions are applications that will be used only briefly, so that every user is a novice, and habituation is not an issue. One example of such an interface is that for a computer-driven kiosk at an exhibition.
The learning phase of working with a feature involves your conscious attention. Therefore, simplicity, clarity of function, and visibility are of great importance. The expert phase is predominantly characterized by unconscious use of the feature; such use is enhanced by such qualities as aptness to the task, modelessness, and monotony. These sets of requirements are not in conflict; therefore, a well-designed and humane interface does not have to be split into beginner and expert subsystems.
This is not to say that an interface must not be split on these lines. However, if you find yourself designing an interface and are tempted to provide "expert" shortcuts, consider whether you should instead redesign the existing method so that it satisfies the needs of all users with one mechanism.