Perpetual Intermediates

Typically, our most powerful tools help us to understand, visualize, and inhabit the personalities of our users. One mental model that we use routinely is called perpetual intermediates. Most users are neither beginners nor experts; instead they are perpetual intermediates. Remember Rupak, Shannon, Dexter, and Roberto from the discussion of skill levels in Chapter 9? Although their backgrounds vary widely, all four of them are perpetual intermediates.

The experience of people using interactive systems as in most things tends to follow the classic bell curve of statistical distribution. For any silicon-based product, if we graph the number of users against their particular skill levels, there will be a few beginners on the left side, a few experts on the right, and a preponderance of intermediate users in the center.

But statistics don't tell the whole story. This is a snapshot frozen in time, and although most people the intermediates tend to stay in that category for a long time, the people on the extreme ends of the curve the beginners and experts are always changing. The difficulty of maintaining a high level of expertise means that experts come and go rapidly. Beginners, on the left side of the curve, change even more rapidly.

Although everybody spends some minimum time as a beginner, nobody remains in that state for long. That's because nobody likes to be a beginner, and it is never a goal. People don't like to be incompetent, and beginners by definition are incompetent. Conversely, learning and improving is natural, rewarding, and lots of fun, so beginners become intermediates very quickly. For example, it's fun to learn tennis, but those first few hours or days, when you can't return shots and are hitting balls over the fence, are frustrating. After you have learned basic racket control and aren't spending all of your time chasing lost balls, you really move forward. That state of beginnerhood is plainly not fun to be in, and everybody quickly passes through it to some semblance of intermediate adequacy. If, after a few days, you still find yourself whacking balls around the tennis court at random, you will abandon tennis and take up fly-fishing or stamp collecting.

The occupants of the beginner end of the curve will either migrate into the center bulge of intermediates, or they will drop off the graph altogether and find some activity in which they can migrate into intermediacy. However, the population of the graph's center is very stable. When people achieve an adequate level of experience and ability, they generally stay there forever. Particularly with high-cognitive-friction products, users take no joy in learning them, so they learn just the minimum and then stop. Only Homo logicus find learning complex systems to be fun.

Now let's contrast our bell curve with the way that software is written. All programmers qualify as experts because they have to explore every obscure case and unlikely situation to create program code to handle them. Their natural tendency to design self-referentially means that they write implementation-model code that gives every possible option equal emphasis in the interaction. If you graph the suitability of use of the typical implementation-model product, it rises high on the right side for experts. The intermediate users don't get much attention.

Inside a company, sales, marketing, and management are always showing off the product to customers, reporters, partners, and investors who are unfamiliar with the product. Of necessity, these professionals are constantly exposed to beginners, and their view of the user community is strongly biased toward this problematic group. All of these influential players naturally lobby for bending the interface to serve beginners. They want to see training wheels attached to the product to help out the struggling beginner. Our graph of the product's interaction suitability now rises high on the left side for beginners.

Superimposing the two graphs makes it clear that not only are the two strongest influences on interaction design antipodal, but they are both largely beside the point. The programmers demand interaction suitable only for experts, and the marketers demand interaction suitable only for beginners, but the largest, most stable, and most important group of users is the perpetual intermediates, who are ignored.

This discontinuity between developers' perception of users and of their true nature results in added cognitive friction. You can easily see this in most internal corporate software and most mass-marketed software-based products. To use them successfully, you need to be a computer programmer, while simultaneously they have a profusion of such artifacts as wizards and on-line help for beginners. These features are merely welded-on training wheels. Wizards and help tend to get users out of scrapes without actually enlightening them as to how to avoid such scrapes in the future. Experts never use them, and beginners quickly desire to discard these embarrassing reminders of their ignorance. But the perpetual intermediates are perpetually stuck with them.

Armed with the Goal-Directed design tools of personas, goals, scenarios, perpetual intermediates, interface inflecting, and others, we can assault a client's design problem with confidence. We know that even the most intractable issues will eventually yield to our process.

"Pretend It's Magic"

Each engineer views his product in different terms, but because he programs he rarely views it in terms of a specific user (at least not to the level of specificity that I find useful). In our brainstorming sessions, we cut through all of the constraints and expectations. We begin our design from a blank slate, but with careful attention to our personas and their goals. We often use a creative-thinking exercise we call "pretend it's magic," in which we act through a scenario with a "magic computer" that has no constraints at all.

This exercise increases the contrast between tasks and goals. When technology changes, tasks usually change, but goals remain constant. By imagining a magic technology, we force all tasks to change, thus highlighting the goals. Although we imagine things to be magic, the process is a very straightforward mental exercise. Sometimes the correct answer appears to the designers in a flash of insight, but just as often it comes as a result of long discussion and study.