Introduction
Why does it feel weird when software tries to be polite? Manners are human social signals, and they usually imply something more than information transfer like gratitude, deference, obligation, goodwill, and ego. Software does not participate in any of that. It does not feel grateful. It does not feel guilty. It does not need to be reassured. So, when an interface says “please” or “thank you,” it can land in the language version of the uncanny valley: close enough to human manners to sound intentional, but empty enough to feel fake. Software should not try to be human. But the opposite of polite is not rude. Instead of sycophantic interfaces, we should build respectful ones.
Saying “Please”
Software should absolutely ask for permission, but begging for it implies a social order that the software does not actually participate in. Software should not say “please” to coax the user into doing something. We know the software doesn’t care if we say “no.” And it definitely should not say “please” when the only option is “yes.” Depending on the context, “please” implies the person being asked has options. They can choose to participate in the request or deny it. I technically have an option if my girlfriend says “please take out the garbage”. There may be serious social consequences to saying “no”, but I still have a choice. When software says “Please click OK to continue” and the only button is OK, it is not asking permission. It is giving a command. Saying “please” is either a way to soften the command or give the user an out. Neither of those apply to an emotionless machine.
The respectful version of “please” is not more manners. It is more clarity. If the user has a real choice, explain the choice and the consequence. If the user does not have a real choice, do not dress the requirement up as a favor. Tools earn trust by being honest about what they need, not by borrowing the language of human deference.
Saying “Thank You”
Why do we say “thank you”? For some of us, our mommies drilled it into our heads so it is automatic. But we say it to express gratitude. “Thank you” implies a transaction. Someone does something and you tell them you are grateful. The giver feels appreciated, or maybe you are trying to win goodwill to extract more favors in the future. These mannerisms serve human egos. Software doesn’t have an ego. It doesn’t get offended. It has no concept of an internal scorecard to keep track of owing the user a favor. So why is it trying to participate in this social contract humans have invented? Sure, I have an ego to stroke, but who is thanking me? It can’t be the software because software has no feelings. Is the company that owns the software thanking me? I know the company doesn’t care about me. They want my business. So, it feels like fake corporate warmth to make me feel good about the company. We recognize fake gratitude and it turns us off.
Like with “please”, software will thank us for something we didn’t have a choice in. “Thank you for enabling location services” is so disingenuous. I didn’t open Google Maps because I wanted to perform an act of charity for a GPS permission dialog. I opened it because I wanted directions, and the product needs my location to do its main job. And it gets worse when the software irritates us. Being told “Thank you for waiting patiently” is infuriating after you have already been sitting there for five minutes. It names an emotion you may not be feeling and tries to manage your reaction instead of the root cause. That is the same reason “calm down” usually fails. It argues with the person’s emotional state instead of addressing what caused it. Slow processes become more tolerable when the interface explains what is happening, how long it may take, and whether the system is still working.
How to Build Respectful Software
Software should not talk up or down to the user. It should not kiss their ass, and it should not act human when we all know it isn’t. Humans are attuned to spotting disingenuous language. Politeness for its own sake is a waste of bytes. Instead, software should respect the user’s time. It should be helpful.
If there is an error, don’t be cute in an attempt to soften the blow. Emojis don’t make me feel better when I’ve lost an hour of work. Be clear about what happened, but not verbose. The user should understand what went wrong at a high level and be guided on what to do next. Don’t put responsibility on the user for the error, even if it is technically their fault. People don’t like to be blamed. On the other side, do not make the apology the whole message. Software does not feel remorse, so the useful part is recovery: what happened, what changed, and what the user can do next.
Here are some common frictions and errors a user may encounter, examples of what not to say, and better ways to handle the situation respectfully.
Waiting for a process
Bad language: “Thank you for waiting.”
Respectful options:
- Show an estimated time remaining.
- List the operations executing.
- Show that the system is still responding.
Why it works:
- Reduces the tension of not knowing what will happen next.
- Gives the user permission not to babysit the process.
Asking permission
Bad language: “Please enable microphone access.”
Respectful options:
- “Enable microphone access to chat in multiplayer?” Yes/No
Why it works:
- Shows a clear request and consequence.
- Avoids emulating human emotion.
Error occurred
Bad language: “Uh oh, something went wrong.”
Respectful options:
- Give a human-understandable description of the error.
- Offer actions the user can take.
Why it works:
- Avoids condescending fluff.
- Expands the user’s understanding of the system.
Unauthorized access
Bad language: “Sorry, you can’t do that.”
Respectful options:
- “This action requires write permissions.”
- If appropriate, direct the user to where they can request permission.
Why it works:
- Does not blame the user.
- Avoids ceremonial apology.
Conclusion
The point is not to make software cold. The point is to stop pretending it has feelings. A respectful interface does not beg, flatter, apologize theatrically, or thank the user for enduring its flaws. It explains what is happening, asks for permission when permission is real, gives the user meaningful choices, and gets out of the way. Software does not need manners. It needs respect.