Let Them Eat Cake

I live and work in Silicon Valley, California. Virtually everybody I know is involved in the high-tech industry. We are all affluent, highly educated, and geographically and socially mobile, and we are all very comfortable with computers, cell phones, DVDs, ATMs, and every other software-based product in the middle-class menagerie. When I eat lunch at the Crescent Park Grill or Spago, the people at the next table are always discussing "client/server this" and "Web-based that." It's an exciting place to live, but it isn't representative of the majority of people in this country, let alone around the world. Here in Silicon Valley, it is easy for our estimation of the suitability of high-tech products to be terribly skewed. We forget how hard these products really are to use.

Ten years ago, retail consultant Seymour Merrin said that we have found it easier to convince consumers that software is easy to use than it is to actually make it easier to use. Merrin was being cynical, but he was also expressing surprise that we were getting away with such a bold lie. His assertion is as true now as it was then, but with the growth of high tech, we cannot continue on mere cynicism we need a real solution.

People know that using computers is very hard, but they assume that there are good reasons for the difficulty. Most people assume that things work as well as they possibly can.

Although most users of software-based products outside of the computer industry are extremely frustrated with hard-to-use products, most of the people creating them are satisfied with the status quo. Programmers don't find using computers particularly hard, so they are willing to tolerate things while they play with technology and have fun creating cool new dancing bearware.

For the rest of us, we get the software that we demand, and so far, we have demanded little. Software vendors give us geegaws, gadgets, and features we don't want and never use, yet we buy them anyway. We demand that our programs don't crash, so our programs are exhaustively tested, and they are reasonably reliable. We demand the newest versions right away, so they ship at breakneck speed. But unaware that things could be better, we don't demand that they be powerful and pleasurable, so they are weak and oppressive instead.

Occasionally, consumers hold out the vague and quixotic hope that the next wave of high technology such as voice recognition will make software-based products easy to use. This hope is naïve and foolish, and it saddens me how the apologists cruelly fan it.

Computer software is precisely that soft and it can be molded into anything that its makers want it to be. They don't make it easy to use because they don't know how, not because it can't be. Rather than admit that embarrassing fact, they claim that it cannot be done for "technical reasons." Computer users, who are not programmers, are forced to agree with the experts and suffer, or to disagree with the experts and what? suffer anyway. Not being experts, they are unable to proffer solutions of their own, so they are just regarded as unproductive complainers.

Detroit used to make huge, chrome-encrusted, gas-guzzling cars and proclaim self-righteously that it "only gave the consumer what they wanted." In the gas crisis of the mid-1970s, the Japanese stepped in with conservative, fuel-efficient small cars and dealt Detroit a blow it will never forget. Today, American auto makers show a much greater respect for the consumer's desires, and they will never again make the claim that they know best.

The Japanese seized the high ground of the auto market by giving users something that they didn't even know they wanted. But they knew a good thing when they saw it. In the same way, the high ground of software interaction is currently unoccupied and up for grabs. Microsoft is as vulnerable today as General Motors was in 1974.

The mass market of low-tech consumers will quickly leap on easy-to-use products, as the explosion of the Web attests. The same people who were attracted to the Web because it does a simple thing simply will be attracted to well-designed products that do complex things simply.

Those low-tech consumers outside of enclaves like Silicon Valley won't demand change because they simply cannot become a cohesive group. Sure, they know good stuff when they see it, but they only see it after it has already been built and put on store shelves.

Change will occur only when the people inside business who have influence early in the product life cycle become interested in fixing this problem. Programmers have a conflict of interest, so my appeal is to the ranks of apologists in the heart of the high-technology industry. And if you are in business today, you are in the high-technology industry whether you want to be or not. There is hardly any business left in the world that is not in the process of becoming dependent on information technology or that has not already become so.

None of our current crop of software-based products is capable of delivering power and pleasure to people outside of the techno-smitten minority. The engineering community says merely that users will have to become "computer literate." I believe history will view that phrase in the same way we treat Marie Antoinette's famously condescending "Let them eat cake." The French Revolution gave food to the masses, and the coming design revolution will give technology to the masses.

Changing the Process

The majority of software engineers and technical managers do what they do now because they believe in the process, but they are not dogmatic about it. They are pragmatic enough to change when they see how effective interaction design is. After they see its value, in my experience, they are very willing to integrate it into their development process.

Software engineers have a long history of changing their spots. Sure, they are engineers and will always think like engineers, but they will adopt new even radical techniques if they can see their effectiveness clearly demonstrated.

Twenty years ago, it was normal in the programming business for software engineers to test their own code. In fact, it was normal for a programmer to assert that he was the only person who could reliably test his own code, that he was the only person who could know all of its weak spots and its dusty corners that needed probing.

Surprisingly, it was also true that although they had to do it programmers almost universally hated testing and begrudged the time and effort it demanded. But programmers did the test work required of them because they conscientiously believed in their role in the process as well as the need for aggressive testing.

Slowly, over the last couple of decades, the idea that a corps of professional testers could separate out this part of the programming job and relieve programmers of its responsibility took root in the industry. After initial skepticism, programmers saw the value. The testers to the enduring astonishment of most programmers actually liked testing. They enjoyed crafting new, ever more diabolical tools for exercising the product, looking for weaknesses and omissions, probing edge cases, and pounding on probable cases. Of course, having products stretched by a trained corps of professional testers was far better than having programmers do it. And the programmers found that a large, unpleasant part of their job not only went away but was now accomplished more reliably, more timely, and with better organization and thoroughness. Contemporary doctrine in software-development circles says that a one-to-one ratio of testers to coders is correct. There isn't a programmer working today who still insists that he is the best person to test his own code.

We will see a similar gradual change occur when design becomes part of the development process. Because of the benefits of adding design, early adopters in this effort will reap those benefits the most.

Software engineers share the goals of the interaction designers: They want the product to be successful. It's just that their tools and terms for measuring that success are dramatically different from those of the designers.

In the absence of any convincing evidence, the programmer will always fall back on her own training, experience, and gut sensibilities. Her guts tell her to provide as many functions as possible. Her experience tells her to not let amateurs disturb the sensitive, difficult, and delicate development process with whims and guesswork. Her training tells her to construct interfaces in her own image.

The interaction designer cannot attack these motivations directly. Developers are too rational to abandon their experience for the opinions of others. The designer must show them a new way of looking at the problem, and he must show them two additional things: that it is effective and that it is compatible with their existing ideas.

Regardless of the strength of the interaction designer's position, it is extremely unlikely that he possesses better knowledge of the program's internals than the programmer. In other words, he cannot possibly take a more accurate look at the problem than from the programmer's point of view. In order to succeed, he must approach the problem from another point of view.

Where interaction designers can approach programmers on an equal basis is in the precision and completeness of the interaction specification. When designers deliver solutions that are compellingly correct, programmers come to trust and depend on them.

In a 1998 article in Business Week,^[1] columnist Stephen Wildstrom broached the topic of frustrated computer users. The response from his readership overwhelmed him with its polarized point of view, its quantity, and its vehemence. It caused him to conclude:

^[1] Business Week, October 19, 1998, "They're Mad as Hell Out There," Stephen H. Wildstrom.

The computer industry has a lot of baffled, frustrated, and unhappy customers. That is a much graver threat to the long-term health of the high-tech sector than the Asian crisis, the Year 2000 bug, or just about anything else.

He reprinted the all-too-familiar cries of pain from the survivors "My machine makes me think I'm an idiot!" along with the equally familiar cries of the apologists "Users don't know what they want, and when they do, they all want something different. And they won't read manuals or learn about programs." He concluded with this interesting observation:

There's one thing missing from this outpouring. I've heard from engineers, programmers, and usability gurus. But the product planners and marketers who make the key hardware and software design decisions have been conspicuously silent. You folks have a lot of angry customers out there. How are you going to respond?

Indeed, how are you going to respond?