The 14 Characteristics of Polite Software, Part 2

September 11, 2017

In Part 1 of this two-part series, I highlighted the study Byron Reeves and Clifford Nass conducted at Stanford University, which showed that people treat computers, Web sites, applications, and other new media just as they treat other people. The study’s findings formed the basis of my article’s core argument: we should strive to design human-like politeness into software.

In his book The Inmates Are Running the Asylum, Alan Cooper describes fourteen characteristics of polite software. I discussed the first nine of those characteristics in detail in Part 1. Now, in Part 2, I’ll cover the remaining five characteristics of polite software, providing several examples.

Champion Advertisement
Continue Reading…

To jog your memory, I’ll reiterate Cooper’s fourteen characteristics. Polite software

  1. Is interested in you
  2. Is deferential to you
  3. Is forthcoming
  4. Has common sense
  5. Anticipates your needs
  6. Is responsive
  7. Is taciturn about its personal problems
  8. Is perceptive
  9. Is self-confident
  10. Is well informed
  11. Stays focused
  12. Is fudgeable
  13. Gives instant gratification
  14. Is trustworthy

10. Polite software is well informed.

Most software presents only the specific data that is strictly relevant to the user’s current task. However, presenting just the most pertinent data for the current task may mean you’re missing out on key opportunities to assist and delight users.

For an example of a human being who keeps people well informed, consider your local TV weatherman, who not only tells you about the weather in your city, but also how it will likely affect your life. In the case of heavy snow, perhaps certain roads will be closed. Or a rare sunny day may provide fun sunbathing opportunities at the local beach. Weather apps, in contrast, just tell you the current and expected weather conditions, providing little or no supporting information. This is a lost opportunity.

One good example of well-informed software is Kayak, the fare-aggregation and price-comparison Web site. I often use Kayak to find the lowest price for airplane tickets. As Figure 1 shows, Kayak gives you additional, useful advice on the optimal time to buy tickets—which is based on their analysis of past and current pricing trends—rather than just lazily listing all ticket prices in ascending order and calling it a day. This is an excellent example of software being informative and giving people the bigger picture.

11. Polite software stays focused.

In The Inmates Are Running the Asylum, Alan Cooper writes:

“Choices are generally not all that desirable, and being offered them is not a benefit, but an ordeal.”

Pakistan-based Meezan Bank has a reputation for being easy to work with because they handle most of the paperwork and low-level decisions themselves. I experienced this myself recently when I opened a new account there. Other than asking a couple of straightforward questions regarding the type of account I wanted and whether I’d like a checkbook, the account manager handled the account-opening process himself. He did not ask me unnecessary questions for that had obvious answers—such as whether I wanted an ATM card, SMS, and Internet banking. Of course, I wanted them!

This hadn’t been the case at my previous bank, where I had to fill out a lengthy form that included dozens of confusing questions and offered several different services among which I had to pick and choose.

Most software—like my previous bank’s account-application form—does not stay focused. For example, in Adobe Photoshop, when I click Save, I expect the application to save an image file in the appropriate format and apply the appropriate settings, so I can quickly share the image. Instead, it presents unnecessary choices that frustrate me every time, as shown in Figure 2.

Figure 2—Photoshop asks unnecessary questions
Photoshop asks unnecessary questions

Here’s another example of a bad user experience: Consider how the application-installation process works on Windows. Most Windows applications use wizards for installation and configuration. These wizards ask questions such where you want to install the application and whether you want to install language packs and additional plugins. It’s a convoluted process.

Compare this with the more focused method of installing applications on macOS, simply by dragging application icons and dropping them on the Applications folder, as shown in Figure 3. There are no other steps! This was a major surprise for me when I transitioned from Windows to Mac.

Figure 3—macOS application installer
macOS application installer

12. Polite software is fudgeable.

Those of you who read Part 1 of this series to the very end will quickly connect the dots and recognize fudgeability as the characteristic that could have been a separate article on its own!

Computerization has fundamentally changed almost every business process over the last few decades. Today, all types of work in every domain are dependent in some way on computers—from simple tasks such as data entry by filling out forms to big chunks of work in design, accounting, finance, or marketing. Technology is so ingrained in the fabric of modern industries that is difficult to imagine how work got done just a few decades ago. The computerization of our lives will only deepen as artificial intelligence, autonomous vehicles, quantum computing, and other advanced technologies become mainstream.

No doubt, the world has gained tremendously from the computerization of manual processes, but through this transition, we have lost fudgeability—a key characteristic of polite software. Alan Cooper describes fudgeability as the “ability to work the system.” We have all witnessed or experienced fudgeability at some point.

Consider the example of shopping at a traditional mom-and-pop convenience store: You came home late at night and realized you’re completely out of some essential toiletries, so you rushed down to the nearest store. On arriving, you saw a Closed sign on the door. But you remembered that, in your town, shops are required by law to close early to conserve power. Determined, you knocked on the store’s window to get the attention of the sleepy cashier. You pleaded with her to give you just two minutes to pick up everything you need.

Because the store uses pen and paper to record transactions and the cashier was courteous, she let you buy your toiletries. She penciled in the transaction on the next day’s records, adding a reminder to ink it in later. You both went home happy. Mom and pop got an extra sale for that day. The local authorities never noticed a thing.

In contrast, if Point-of-Sale (POS) software had powered transactions at this convenience store, you would have been out of luck. The cashier would have just shrugged, telling you there’s no way to process your order after closing. The software doesn’t support fudgeability the way pen and paper can.

Computerized systems tend to sacrifice fudgeability for easy compliance with legal requirements. In such systems, user data has two states—it is either nonexistent or fully compliant. Manual systems are more flexible, or fudgeable. They allow a third state in which user data can be incomplete or even incorrect, allowing workers to process orders, knowing they can resolve data inconsistencies later.

Fudgeability is arguably the most challenging characteristic of polite software to build into modern systems. Designing and implementing fudgeability requires extra effort on the part of both designers and developers. It also requires management to identify the line not to cross—where fudging becomes fraud or abuse or has some other nefarious purpose. Fudging, then forgetting to complete a temporary fudge could snowball into bigger problems that could lead to loss of life, property, or both. Of course, businesses don’t want any of that, so they’re willing to work with software that does not support fudging. Developers rejoice at the simplicity of systems that don’t allow fudgeability because they can build software that follows an easier implementation model.

But it is possible to create software that strikes the right balance between fudgeability, legal compliance, and business requirements. KeepTruckin, an electronic-logging mobile app for truckers, and a related Web dashboard for fleet managers provide good examples of such software. To support truckers, the developers literally translated their manual, pen-and-paper logs, shown in Figure 4, into a mobile app, shown in Figure 5. The mobile app supports fudgeability just like the manual system. In fact, fudging is arguably easier using the app because the user can just drag a few sliders to edit their logs. With paper logs, editing entries left noticeable marks on the paper.

Figure 4—Traditional pen-and-paper log
Traditional pen-and-paper log
Figure 5—A digital log in KeepTruckin
A digital log in KeepTruckin

By end of 2017, the entire US trucking industry must automate its logs by connecting an electronic device directly to the engine, as required by law. KeepTruckin also has an app for that automated system. Using such devices in conjunction with the mobile app reduces fudgeability—thus, maintaining legal compliance because truckers cannot edit their driving logs—but it still lets them edit other data. I find KeepTruckin to be an excellent example of a manual process that has survived and even thrived after computerization—because it meets all key stakeholders’ requirements.

For examples of apps that lack fudgeability, just play around with some of the apps on your phone. For example, no to-do list app is as flexible as paper. Nor have I found a half-decent app that lets me visualize tasks in quadrants, according to their importance and urgency. As far as I know, no journaling app supports audio logging and note entries, allowing me to archive them. No cash-based, expense-tracking app can accurately categorize all types of expenses or easily support your specific financial requirements. I’d be ecstatic if you could prove me wrong!

13. Polite software gives instant gratification.

Humans are impatient creatures, and we don’t play well with others who act as obstacles to our winning rewards. Toddlers bawl their eyes out if they don’t get their sweets immediately. Even full-grown adults sometimes become agitated if it takes too long for a restaurant to serve dessert. We humans want our sweets, and we want them now! In his book The Inmates Are Running the Asylum, Alan Cooper quips:

“Computers do nothing until you’ve put enormous effort into first writing a program. Software engineers slowly internalize this principle of deferred gratification, and they tend to write programs that behave in the same way.”

The results of this mentality are all too familiar. Most applications require you to fill out long forms before they’ll give you some desirable outcome. Consider services such as Netflix and Apple Music, which require users to set up a payment method before they can even try the service. Doing this might be fairly easy for people in developed countries, but for everyone else, this can be a really frustrating process. As Figure 6 shows, Spotify provides instant gratification by letting new users use their Premium service on a trial basis, then, if users haven’t added a payment method, shifting them to the free service once the trial period is over.

Figure 6—Spotify lets users listen to music immediately after signing up
Spotify lets users listen to music immediately after signup

14. Polite software is trustworthy.

It is useful to think of trust as a virtual bank account. We create a new account for every new person we meet. Each time someone is honest, kind, or dependable, we deposit trust in their account. Similarly, each time someone is rude, unkind, or doesn’t fulfill their responsibilities, we withdraw trust from their account. When a person’s account is overdrawn, people stop trusting him or her.

Keeping this metaphor in mind, it is easy to see why people don’t generally trust computers. Over the years, most people have been let down by their software in one way or another—experiencing everything from data loss to missing functionality, general unreliability, or difficulty of use. As a result, people find it difficult to trust software. So we think twice before buying a $5 app, but don’t think much at all before buying a coffee at the same price.

To compensate for this, software companies use psychological devices to establish trust. They spend millions on advertising to build their brands. Companies such as Apple and Google have built users’ trust by spending billions on marketing over many decades, so people trust them with their money and personal data. Smaller companies use social proofs for the same purpose, adding testimonials and positive reviews to pages on their Web site. Startup companies associate themselves with popular incubators and accelerators to get prospective clients to trust them. All this extra effort would not be necessary if software and computer manufacturers would simply built trust by making their products reliable and relatable.


The idea of designing politeness into software caters to the human tendency to treat applications like people and has opened my eyes to the relationship between psychology and UX design. To err is to human, so understanding how and why we err is an important part of designing better products.

If you found this topic interesting, you should consider reading Alan Cooper’s The Inmates Are Running the Asylum, which inspired this article. Then, follow up by reading Daniel Kahneman’s award-winning book, Thinking Fast and Slow, and Susan Weinschenk’s popular book 100 Things Every Designer Needs to Know About People

Co-founder and Head of Content and Design at PriceOye

Islamabad, Pakistan

Awais ImranAwais is an Internet entrepreneur, UX designer, writer, and public speaker. He is co-founder and Head of Content and Design of Pakistan’s leading price-comparison startup He is also Curator of a popular Facebook group for the Pakistani design community, UX Design in Pakistan. A passionate writer and speaker on design, personal growth, and entrepreneurship, Awais has contributed articles to Tech in Asia, MIT Technology Review PK,, The Express Tribune, and Tech Juice and has spoken at community events in Pakistan, including at Google, Telenor, and TED.  Read More

Other Articles on Software Design

New on UXmatters