Now let's contrast our bell curve of intermediates with the way that software is developed. Programmers qualify as experts in the software they code because they have to explore every possible use case, no matter how obscure and
At the same time, sales, marketing, and management—none of whom are likely to be expert users or even intermediates—
Programmers create interactions suitable only for experts, while the marketers demand interactions suitable only for beginners, but—as we have seen—the largest, most stable, and most important group of users is the intermediate
It's amazing to think that the majority of real users are typically ignored, but more often than not that is the case. You can see it in many enterprise and commercial software-based products. The overall design biases them towards expert users, while at the same time, cumbersome tools like wizards and Clippy are grafted on to meet the marketing department's perception of new users. Experts rarely use them, and beginners soon
Optimize for intermediates.
Our goal should be
We need to
Beginners are undeniably sensitive, and it is easy to demoralize a first-timer; but we must keep in mind that the state of beginnerhood is
an objective. Nobody wants to
As an interaction designer, it's best to imagine that users—
Imagine users as very intelligent but very busy.
On the other hand, intelligent people always learn better when they understand cause and effect, so you must give them an understanding of why things work as they do. We use mental models to bridge the contradiction. If the represented model of the interface closely
A new user must grasp the concepts and scope of the program quickly or he will abandon it. Thus, the first order of business of the designer is to ensure that the software adequately reflects the user's mental model of his
To get beginners to a state of intermediacy requires extra help from the program, but this extra help will get in their way as soon as they become intermediates. This means that whatever extra help you provide, it must not be fixed into the interface. It must know how to go away when its services are no longer required.
Standard online help is a poor tool for providing such beginner assistance. We'll talk more about help in Chapter 35, but its primary utility is as a reference, and beginners don't need reference information; they need overview information, such as a guided tour.
A separate guide facility—displayed within a dialog box—is a fine means for communicating overview, scope, and purpose. As the user begins the program, a dialog box can appear that states the basic goals and tools of the program, naming the main features. As long as the guide stays focused on beginner issues, like scope and goals, and avoids perpetual intermediate and expert issues (discussed below), it should be adequate for assisting beginners.
Beginners also rely heavily upon menus to learn and execute commands (see Chapter 27 for a detailed discussion about why this is true).
Experts are also a
Experts might occasionally look for esoteric features, and they might make heavy use of a few of them. However, they will definitely demand faster access to their regular working set of tools, which may be quite large. In other words, experts want shortcuts to everything.
Anyone who uses a digital product for hours a day will very quickly internalize the
Expert users constantly, aggressively seek to learn more and to see more connections between their actions and the program's behavior and representation. Experts appreciate new, powerful features. Their mastery of the program insulates them from becoming disturbed by the added complexity.
Perpetual intermediates need access to tools. They don't need scope and purpose explained to them because they already know these things. ToolTips (see Chapter 29) are the perfect perpetual intermediate idiom. ToolTips say nothing about scope and purpose and meaning; they only state function in the briefest of idioms, consuming the least amount of video space in the process.
Perpetual intermediates know how to use reference materials. They are motivated to dig deeper and learn, as long as they don't have to tackle too much at once. This means that online help is a perpetual intermediate tool. They use it by way of the index, so that part of help must be very comprehensive.
Perpetual intermediates will be establishing the functions that they use with regularity and those that they only use rarely. The user may experiment with obscure features, but he will soon identify—probably subconsciously—his frequently used working set. The user will demand that the tools in his working set are placed front-and-center in the user interface, easy to find and to remember.
Perpetual intermediates usually know that advanced features exist, even though they may not need them or know how to use them. But the knowledge that they are there is reassuring to the perpetual intermediate, convincing him that he made the right choice investing in this program. The average skier may find it reassuring to know that there is a really scary black diamond expert run just beyond those trees, even if she never intends to use it. It gives her something to aspire to and dream about.
Figure 3-1: The demands that users place on software vary considerably with their experience. The tools presented to the user need to reflect this disparity. Your program won't be appreciated much if its best quality is that it is very easy for first-timers to learn, since most users will quickly become perpetual intermediates. Similarly, if only professional,
Your program's code must provide for both rank amateurs and all the possible cases an expert might encounter. Don't let this technical requirement influence your design thinking. Yes, you must provide those features for expert users. Yes, you must provide support for beginners. But you must apply the bulk of your talents, time, and resources to designing the best interaction possible for your most representative users: the perpetual intermediates.