Flow, Tolerance Capital, and Ease-of-use Features

Think about something you love to do, and think how you feel when you're very focused at it. Maybe you love to take photographs, ski, play the guitar, ride motorcycles - whatever it might be. When you're immersed in that activity, you get a sense of flow where each action comes naturally from the last, you're focused on your goal (or on nothing at all) and you're not aware of the mechanics of what you're doing. Then suddenly something goes wrong with one of your tools. The camera starts taking half a second longer to auto-focus, your ski boot comes loose while turning on a mogul, a guitar string goes out of tune, the throttle sticks for a fraction of second just when you want to speed up, and so on. These are all small bumps and "bobbles," and they're easy enough to compensate for. But they're annoying because they get in the way of what you care about. They break your flow.

If these small problems keep happening, you try to fix the cause, annoyed that you have to spend your time fixing your tools. And if these flaws keep breaking your flow, eventually you get another tool. It's as if you grant your tools a certain amount of points, or "tolerance capital," based on how much you value the features it provides. Each time your tool breaks your flow its capital declines. If the difficulty of using something starts to outweigh its value, you stop using it (unless you're forced to use it, say for your job). Unfortunately for most people, much of the computer technology in our lives hovers just above the break-even point, leaving us in a love-hate relationship. Yes, technology lets us do things we couldn't do before, but we often don't enjoy using it and we usually end up feeling more frustrated than pleased with the result.

Why does this happen? Most people who build technology want to build quality products and they want people to enjoy using them. We believe the main problem is that the technology industry is set up to compete on numbers of features, not on the usefulness of products. The development team makes a list of features, marketers list those features on the promotion materials, and product reviewers make matrices comparing the number of features across competing products. In this world, more features is better than fewer. Sometimes, a product will list "Easy to Use" as a feature, but since there are no criteria for such a claim (having a graphical user interface or a Web interface is apparently enough to qualify), just saying it's true doesn't help you compete.

Meanwhile, the mass media and trade publications have been complaining for years that technology is so complicated that people can't use it. This book's Preface includes excerpts from such articles going back to 1991 when Business Week ran a cover story called, "I Can't Work This Thing." Ten years later, with many similar articles in between, U.S. News and World Report took on the same problem in its cover story, "High-Tech Overload." All these articles complained about the same thing - too many features and not enough focus on usability. Reducing features may seem risky, but there is evidence that people will be loyal to and spread the word about usable technology, converting their friends who complain about their annoying technology. Alan Cooper makes this case about Apple, whose loyal fans have ardently stuck by it, even as the company charged higher prices for a platform that had fewer applications. Prior to the debut of the Palm Pilot, there had been many attempts to market a handheld organizer device using handwriting recognition, all of which failed with great fanfare (e.g., Go, Apple's Newton). Now the Palm is widely recognized as one of the most useful and best-designed technology products available. Walter Mossberg, the influential and respected technology columnist for The Wall Street Journal, raves about the Palm, saying it has a "brilliant user interface."

Wouldn't it be nice if people using your technology said as many nice things about it as they say about the Palm? You can make this happen by paying attention to the user's flow and doing everything you can to remove those small bobbles along the way. Making a feature flow is just as important as implementing the feature itself. Since most projects are organized by listing features and checking them off when they are done, you can work within this system by creating a concept of "ease-of-use features," which are features that remove the bobbles in other features. A feature isn't done until its associated ease-of-use features are done. Before starting a project, the engineers, designers, marketers, and management have to decide if they are willing to devote time and energy to ease-of-use features instead of "check off" features that most people won't use. You have to decide if you want to build something people really want to use rather than something people will buy once and complain about.

It's the Relationship, Stupid

Okay, let's assume you're signed up to build something useful and usable. Now what? The first thing to do is realize that when you're building technology, you're not just building a tool with features. You're building a something that has a relationship with its users. Your tool reacts to people; it changes what it does depending on what they do. It offers to do things for people, and even asks how they would like it done. It asks people for information so it can do its job better. Sometimes it makes mistakes and tries to explain what went wrong. Meanwhile, people learn what your technology can do and how to ask for things. They change their behavior based on the responses they get. Sometimes they are delighted with it, sometimes they become frustrated with it. Sounds like a relationship.

Okay, it's not a deep relationship, and it's definitely not an equal one. Your technology is supposed to do things for people, not the other way around. But a relationship it is, and that means that people bring to it a rich set of expectations about appropriate behavior. The more you understand those expectations, the more pleasant you can make that relationship.

A good model for the type of relationship we're talking about is that between a butler and an employer. Not that either of us has any direct experience with butlers, but we've seen enough movies to form a healthy stereotype. A movie butler is always available, and when asked to do something, he is prepared to do it, with few questions and no complaints. If there is a problem, he finds a way to fix it or work around it without bothering the employer. (Also, he has an English accent.) Since he doesn't want to disturb his employer, he rarely interrupts to suggest ways he can be helpful. Instead, he pays attention to what his employer has done in the past so that he can better anticipate what she will want in the future. Still, he doesn't go overboard in anticipating her needs because he knows it is more costly to do something the employer did not want than it is to not take the extra step. Realizing his demeanor is as important as his competence, he makes a special effort to be courteous and respectful, even when she asks for things he cannot do.

In the meantime, the employer observes what the butler can do and what he does well. She doesn't ask the butler to tell her how to make requests; that would be awkward. Picking up on his feedback, she gradually learns that she gets better results if she asks one way rather than another. Over time, if they have a good relationship, they learn to work together without noticing the interaction. They learn to collaborate.

Your goal in building technology is to teach it how to behave like a movie butler. To do that, you have to teach it how to collaborate.

How to Collaborate

All social activities have certain conventions for appropriate behavior. When we have a conversation, dance, play in a band, drive, build a house, share a meal, and so on, we follow conventions. Usually they are unspoken, and sometimes they are arbitrary, but they let you know what you can expect of others so you can work together more effectively. You can think of them as rules of polite behavior: While driving, signal when you want to change lanes. Applaud at the end of a play. Raise your hand when you want to speak. Collaborating is all about adopting these conventions so you can focus on the more interesting aspects of the activity.

For decades, social scientists have been studying collaborative behavior, and conversation in particular. We draw from some of their observations in drawing up our own rules about how technology should cooperate with people. There are two types of politeness, negative politeness and positive politeness. To be negatively polite one should do no harm: Don't ask too much of people, don't impose, don't offend. How does technology impose? It asks people to put in lots of effort for a small benefit. It overwhelms people with too many options so they can't find what they want. It asks people to keep track of too many things. At a minimum, you want your technology to be negatively polite so it's not seen as rude. This in itself is a challenge and most technology doesn't accomplish it, so just getting that far can make your technology stand out from your competition.

If you want to delight your users, you can design it to be "positively polite" by actively cooperating. It's difficult to list all the ways you can cooperate, but back in 1967, a linguist named Paul Grice came up with a set of principles called the Cooperative Principle for Conversation, which we use as our guide. It consists of four rules, called Quantity, Quality, Relevance, and Manner. The Quantity Rule says you should offer just the right information for the circumstances, not too much and not too little. For example, suppose you ask a shop clerk, "Do you take personal checks?" It is more polite to respond, "I'm sorry, no, but we take credit cards, debit cards, and cash" than it is to say just, "I'm sorry, no." The first answer is better because it addresses your goal of paying for something, probably using something other than cash, and offers reasonable alternatives. But you also don't want to offer too much information. If you stopped to ask someone directions, and that person told you every street you would cross and every landmark you would pass along your way, they would be uncooperative by making it too hard for you to remember the important information.

The Quality Rule basically says, "Don't lie or blatantly mislead." Enough said. The Relevance Rule addresses expectations that are raised by choosing to give certain information over others. If I mentioned that my printer is out of paper and you said, "There's a supply cabinet around the corner," by the Relevance Rule, I would take you to believe that paper is stored in that cabinet. If I found out you knew there was no paper in the cabinet, I would figure you were playing a joke on me or just being mean. Finally, the Manner Rule says to be clear, i.e., to say things in a way that the other person can understand.

We've taken these ideas and converted them into a set of rules for building cooperative technology.

Cooperative Principle for Technology

Don't Impose (negative politeness)

Respect the user's physical effort

Respect the user's mental effort

Be helpful (positive politeness)

Offer sufficient information early and in context, prevent errors (Quantity)

Solve problems, don't complain or pass the buck (Quantity)

Be predictable (Quality)

Request and offer only relevant information, don't mislead (Relevance)

Explain in plain language (Manner)

We do not offer these rules just for the sake of politeness. The rules are useful because they allow you to forget about the mechanics of the interaction and instead focus on the interesting stuff - the activity you came for. If your technology allows people to rotate complex figures in 3D, you want them thinking about how their object looks from the top, not how to get it to rotate. If you enable people to send messages through a small, handheld device, you want them thinking about the conversation, not how to enter text. If your technology enables people to see where they are on a map, they should be focusing on the destination, not how to get the map to zoom out. By following rules of cooperation, you help people focus on their task.

In the next three chapters, we show how to apply the Cooperative Principle for Technology. We break down these rules into further guidelines, giving positive and negative examples from a broad range of technologies. We hope to help you develop the mindset needed to build cooperative technology, regardless of whether it's traditional PC software or the latest "information appliance." Then we'll move on to show you how to apply that mentality in the day-to-day process of building technology.

Next excerpt >