Software is a conversation with your users. And yet historically, the “person” talking to you when you use most software is a passive aggressive asshole.

Let’s take one of the simplest examples, present on thousands of forms across the world wide web – the submit button. Submit. How does that make you feel? Is the software talking to the user? Is the user talking to the software? Is barking out a terse ‘submit’ ever a nice thing to say? (Don’t answer that.)

Confusingly, language is an incredibly powerful AND weak tool in software user experience design. Google built its ad business based on text advertisements, not the flashier graphically heavy display advertising. Headlines on blog posts make all the difference in the world when it comes to enticing someone to click. And yet, we know that most of the text found in software user interfaces simply isn’t read. Users are perpetually scanning, skimming, and jumping around trying to do the least work possible to understand how to accomplish their goal.

Let’s listen in on the traditional thinking:

A concept is hard to explain to the user with only a self-evident user interface? No problem, just put it in the user manual. And as for the user… RTFM!

But…

…manuals are now extinct. So when we have something that’s hard to explain, how about putting in a bunch of explanatory text? The user will read the text in the actual user interface and then understand the complexity of the software.

But we know users won’t read it, and will be confused, so what is the answer?

The answer is the respectful helper.

While depending on the brand of the software experience the voice of a piece of software can vary to a certain degree, the baseline to start with is that of someone friendly, but not overly familiar, and ultimately there to serve – an incredible server at your favorite restaurant perhaps? There when you need them, gone when you don’t. Not overly familiar, but definitely putting you at ease. Efficient in language — definitely not verbose. And ultimately focused on serving the user effectively without being overly familiar or chummy.

Some thoughts on language in software:

• Coherence. Whatever your tone is, it needs to carry throughout the experience. On your website, in your app, when someone talks to tech support, in the marketing materials, and even when watching a demo at the trade show booth (or whatever it is people do instead of trade shows these days). Your software, your company needs one voice. One coherent voice. If the ads speak in one voice, and the product in another, your customers will experience the cognitive dissonance of realizing their date doesn’t look like the picture in the person’s dating site profile. Nobody wants that.
• Friendliness. Walk the line between informal and overly familiar. There’s no need for ma’ams and sirs when it comes to software text. But, being too friendly makes people uncomfortable. And ultimately, software is someone you work with — occasionally, not a member of your family or a boss. Say please and thank you.
• Brevity. Your users don’t read. And even when they do, they don’t comprehend. Not because they lack reading comprehensions skills, but because they have better things to do than read your essays explaining the complexity of your software. If you need to “explain” something with a paragraph of text in the user interface, you’ve already lost. The less text on the screen, the more chance they’ll read what remains. Edit edit edit.
• Testing. Test that text. When it comes to driving users to act. There’s really no better way to know what users will respond to best than testing a few options. That headline, that subject line, that link text, that text ad, can all be tested. Whichever drives the most customers to take the action (and be happy they took it) is the right line. Some people are better than others at writing text that drives action, but nobody is a perfect predictor. Testing trumps all on this one.

If all this is too much, do this simple test. When you write a piece of text for your user interface, say it aloud. To another person. Seriously. Are they annoyed? Do they want to punch you? Are their eyes glazing over? If so then you need to rewrite that text or get rid of it entirely.

In fact, let’s summarize this entire piece of advice. To quote a famous Rabbi out of context, When it comes to using language in software user experiences, “that which is hateful to you, do not do to your user.”