Choose Your Words Wisely: 9 Tips that will Improve Your UI Text

I just googled half a dozen phrases related to the text used in software UI hoping to find a couple interesting ideas to add to this post. I found very little.

While that doesn’t help me write an in-depth article quickly, it does prove the point I want to make–we don’t pay enough attention to the language we use in our user interfaces.

A Meeting About The UI Text? Not Usually.

I’ve participated in long discussions about why Blanched Turquois is the perfect shade of blue for the UI because it contains the meditative qualities of the Atlantic ocean at sunrise. (I’m exaggerating. But not much.) There have been even longer meetings debating whether we should use widget A or widget B and whether the OK or Cancel button should come first. But I’ve never sat in a meeting where the language used on screen was given more than an occasional tweak. Which is weird.

Look at these screens.

• 

• 

Normal                                                                 No Colour

• 

• 

Different widgets                                             No words

Screen 1 is a screengrab from Microsoft Word.

Take out the colour on the second screen… it’s still usable. (Ok, this isn’t the greatest example to prove my point about colour, but you see where I’m going.)

Change the drop down boxes to text fields in the third screen… it’s still pretty usable.

Take out the words in the fourth screen… not so usable.

So what should you be doing when writing the text for your application’s UI?

1.     Use a “Word” Person

I want to tell you here to work with a writer. But I know that isn’t always possible. However, you can usually work with someone who thinks that language is important and who takes pride in clear concise writing.

You also need to make sure that person has the time. There may not be many words on the screen but getting them right takes a lot of time. (If you doubt me, ask me how badly I misquoted the project when I was hired to review and rewrite the UI text for a company whose user experience person was not a native English speaker. Lesson learned.)

It should go without saying but, make sure this person understands your subject matter, the end users’ vocabulary, and common software terminology.

2.     Listen to Users and Use Their Words

We often talk to customers and end users about features and workflows, but we don’t always pay attention to the exact words they are using. Whether you are interviewing customers, doing usability tests or reading online product reviews, note specific words that are used for features or interactions and then use those words.

3.     Think About the Jargon

You often hear advice to keep the jargon out of everything. But I think it’s better to say that any jargon you use has to be commonly understood by your audience. If you were developing an application for a particular scientific niche and you wrote all of the text so it was understandable for someone with a grade 8 education, your intended audience probably wouldn’t be impressed and may question your credibility.

4.     Natural Language

Write naturally. Don’t worry about dangling modifiers or if the feature names are technically correct. If people say it a certain way, write it that way.

I worked with a team developing an application that controlled hardware that included a laser. We labeled the button that activated the laser “Shoot” because that is what every user we talked to said. This frustrated some of our team members because it was technically incorrect. So we tested the “proper” term and no one knew how to make the function work. The lesson was clear, if everyone calls something a flibity-goop, you call it a flibity-goop.

5.     Be Brief But Not to Brief

There is a tendency to try to capture complex concepts in a word or two for UI labels. This probably evolved from low-resolution monitors (and it is still a concern with small screen mobile devices). However, I think the best approach is to use as many words as necessary to convey the concept but NOT. ONE. WORD. MORE. (Making that work for mobile apps is a whole other can of worms).

This means don’t be afraid to use a phrase to label a checkbox or field when necessary but don’t write entire sentences everywhere either.

6.     Keep it Conversational

I find it’s useful to think of the interaction between the UI and the user as a conversation where the UI is walking the user through a task. This conversation works best when you write the words you’d say. You don’t usually tell someone to “enable,” you tell them to “use” or “set” something so write it that way.

7.     Error Messages Should Help the User

I bet you’ve come across errors like these:

Error messages should be written for people. And they need to help people who are currently frustrated because your software didn’t do what they wanted it to. This probably isn’t the time to get too cutesy.

A good error message should:

• Explain what happened

• Suggest a solution

• Ask the user what they want to do

• Have action buttons that answer the question in the last point clearly (OK and Cancel don’t always make sense)

• Be humble and NOT blame the user

8.     Use a Consistent 1st or 2nd Person Voice

Make a conscious decision about whether you are going to use first person (I, my) or second person (you, your) pronouns in the UI or avoid them altogether. Then be consistent.

Avoiding these pronouns sounds like a great idea, but somehow there always seems to be a place you need to differentiate the user’s email address from another email address, or the link to their account info doesn’t resonate with them when you label it Account. Then you end up throwing in a “Your” or “My” without thought.

You can also continue the conversation metaphor using both first and second-person pronouns. If the app is talking to the user, use “we” and “you”, if the user is replying with what they want to do, use “I.”

Think about how you are going to refer to genders when you need general references. His/Her and he/she gets old quick. All masculine pronouns will offend someone. Using feminine pronouns can sound like you’re trying too hard to be politically correct. My preference is to use “they” and “them” for generic individuals. Language is evolving, and thank god this is one change that is quickly being adopted.

In the end, the decisions are yours. What works best for your app depends on your brand identity. The key is to be consistent. Which brings me to my last point.

9.     Create a Style Guide

Put some thought into whether you will use “email” or e-mail,” and “Internet” or “internet.”

Does it really matter which way you go? Again it depends on your brand personality. (But if your brand is young and current, you probably want “internet.”) The main thing is consistency. These little decisions don’t seem that important. But it can be difficult to get changes approved when you realize you called the flibity-goop a goopity-flibbit in a couple places, causing uses to wonder what the difference is. So start with a plan you can stick to.

When a decision is made on tone, feature names, common labels etc. put it in a style guide.

And follow the style guide. No ifs, ands, or buts. You don’t get to make an exception because you are the product manager. You don’t get to make an exception because you’re the CEO. You don’t get to make an exception because you are the writer. If the exception is REALLY necessary it’s probably time to re-evaluate what’s in the style guide.

Wording consistency is key to the “learnability” of an application.  If you call something an orange (or flibbity-gop) in one place, it can’t be a tangerine (or goopity-flibbit) somewhere else.